2011年在金蝶，部門組織了一個培訓，由一個資深的老前輩（紀大松）講了一次23種設計模式，當時懵懵懂懂，對設計模式不屑一顧。如今時隔6年，忙里偷閑，我又將23種設計模式看了一遍，依然不屑一顧。6年前不屑一顧，其實是似懂非懂，如今不屑一顧，就真的是不屑一顧了。
說不屑一顧，并不是說設計模式沒有屌用，反而，我對總結出這套理論的大牛們心存感激亦存尊重。我想表達的是，“設計”，“模式”這兩個詞看起來似乎很高大上，好像自己沾點邊那就跟架構師乃至技術總監相隔不遠了，但卻并不如大家想象的那樣遙遠和高深。
我面過一些人，也被很多人面過，在面試java時設計模式是很常見的話題，很遺憾的是，幾乎所有人討論的都是設計模式本身，諸如：你用過哪些設計模式啊？原理什么樣的？畫個類圖看看？使用場景有哪些？門面模式和代理模式有什么區別等等。我曾經遇見過一位同事，可以說是個技術面很廣的人，你隨便說個技術名詞能跟你講一大堆，23種設計模式你隨便挑一個，他都能準確的幫你把概念，類圖，優缺點，適用于哪些場景“背”出來。但是看過他的代碼后，我很悲哀。
在我認為，真正懂得設計模式的人，是不需要去記那些繁瑣的名詞以及概念的，因為“設計模式”對他們來說是“不屑”的（除非他刻意去記）。因為：

1.設計模式只是一些優秀經驗的積累，
舉個栗子：老板說要模擬一個小孩哭的場景，這小孩一哭就哇哇哇。
報告老板，寫完了。
public class Baby {
public void cry() {
System.out.println("wa wa wa!");
}
}
老板又說了，家里有條狗，小孩一哭，狗也跟著叫。
好吧，改一改，先加條狗：
public class Dog {
public void bark() {
System.out.println("汪汪汪！");
}
}
然后，小孩一哭，狗就跟著叫
public class Baby {

private Dog dog;

public void cry() {
System.out.println("哇哇哇!");
if (dog != null) dog.bark();
}
public Dog getDog() {
return dog;
}

public void setDog(Dog dog) {
this.dog = dog;
}
}
老板又說了，主人還養了貓，貓也跟著叫
好，再改
public class Cat {
public void bark() {
System.out.println("喵喵喵！");
}
}
public class Baby {

private Dog dog;

private Cat cat;

public void cry() {
System.out.println("哇哇哇!");
if (dog != null) dog.bark();
if (cat != null) cat.bark();
}

// getter and setter
}
老板又說了，還有雞，雞還不少，好多只。
如果你還認為要這樣繼續加下去我覺得你是一個不合格的程序猿，我相信大部分人肯定會尋思怎么改了，怎么更容易讓老板的需求變得容易實現:
先抽象一個動物，dog和cat直接實現它
public interface Animal {
void bark();
}
public class Cat implements Animal {
public void bark() {
System.out.println("喵喵喵！");
}
}
public class Dog implements Animal {
public void bark() {
System.out.println("汪汪汪！");
}
}
然后改Baby
public class Baby {

private List<Animal> animals = new ArrayList<Animal>();

public void cry() {
System.out.println("哇哇哇!");
for (Animal animal : animals) {
animal.bark();
}
}

public void addAnimal(Animal animal) {
animals.add(animal);
}

// getter and setter
}
現在好了，老板，你家愛有多少動物就有多少吧。
我相信任何一個不懂設計模式的程序猿，稍微有些工作經驗，只要有心優化這段代碼，不想再被老板無休止得加動物而煩惱，這段代碼寫出來并不難，而這就是23種設計模式中的監聽者模式。即使你連設計模式是什么也不知道，只要有心寫上若干年，某天突然來看，你會發現，幾乎所有的設計模式你都用過。

2.設計模式更多的只是一種思想，而不在于代碼
再舉個例子，還是小孩哭，小孩一哭媽媽就喂奶。某某對于設計模式非常“精通”，于是這樣寫：
public interface IMother {
void nurse();
}
public class Mother implements IMother {
public void nurse() {
System.out.println("乖寶寶別哭！");
}
}
public class Baby {

private List<Mother> mothers = new ArrayList<Mother>();

public void cry() {
System.out.println("哇哇哇!");
for (Mother mother : mothers) {
mother.nurse();
}
}

public void addMother(Mother mother) {
mothers.add(mother);
}

// getter and setter
}
不好意思，老板，作為一個老司機，你所有的需求變化都在我的預料之中，隨便你怎么變，我都能滿足你，因為我用了設計模式中的監聽者模式！！
老板：你他媽腦袋有包，小孩能有幾個媽？？？

spring mvc的controller，service類并沒有要求寫成單例模式，也沒有寫工廠，但是實際上這些類spring都是生成的單例，而且所有實例統一管控。這不正是單例模式和工廠模式的思想么？當你真正明白這些思想時，并不會拘泥于這些模式。

另外也說一點，真正好的設計，并不是基于你用了多少設計模式，而是基于你對當前業務和業務擴展性的理解，非要把一些不會擴展的地方寫成松耦合，濫用設計模式，只會導致工作量增加和類泛濫！

所以，請所有的面試官們，如果你仍然為自己“懂”那么多設計模式而感覺高高在上，請停止你那些愚蠢的提問，因為很可能一個真正的程序猿就被你的無知給篩掉了。

設計模式體現在每一行追求完美的代碼中，而我們無須追尋！
謹以此文獻給那些總在力求讓自己的代碼更加優美，更加易于業務擴展的程序猿們。

總結

以上是生活随笔為你收集整理的我对设计模式不屑一顾的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。