用 C++ 編程時，如果不使用設計模式，多層封裝，採用複雜的數據結構，代碼更直觀，易理解，引入（設計模式）後雖然做到了高度的解耦。但是代碼邏輯複雜了，怎麼平衡好？

01-06

設計模式是從已經完成的代碼和設計中提煉的，不是在設計和編碼之前構思的。

永遠不要為了眼前不存在的需求引入設計模式，更不要為了美化代碼而引入設計模式，這些都是過度設計最直接的根源。

引入設計模式最恰當的時機是需求變更的時候對代碼的重構，而且要注意，一次重構只引入最少量的設計模式，能滿足本次變更的需求即可。

《樸實的C++設計》

http://www.iteye.com/topic/736269

《關於Java開發不明白的一些問題》「解耦不過是一個用來迷糊人的手段,是追求過度設計的人顯擺的工具。只有真正的內聚,沒有絕對解耦,但凡你在某個地方切斷聯繫,那麼你必然會在另一個地方重新產生聯繫」

http://www.iteye.com/topic/947017

不是沒有真正意義上的解耦，是狹義上的設計模式（面向介面編程）做不到真正意義上的解耦。設計模式的主要目標是重用，而不是解耦。

複雜性是客觀的，不會因為你用了什麼模式，什麼數據結構而變得簡單。

但是好的數據結構，合適的設計模式能讓人更容易理解一個複雜的系統。

這就是OOP,AOP,設計模式的作用。

人很難一下理解一個龐大的系統。

更容易理解其中的小模塊。

你可以用OOP的思想不斷優化你的代碼，減小耦合，減少重複代碼。最終你會發現設計模式就在其中。

在做設計模式的時候應該想好/溝通好哪些需求可能變更，解耦不是為了代碼好看，而是為了代碼好改。

多層封裝，採用複雜的數據結構，代碼更直觀，易理解-----自己容易理解，不等於別人容易理解，或者你再過一段時間看看，說這話的人基本都是思維沒有扭轉過來。習慣了局限於自己代碼習慣，可能看優雅的代碼都不習慣。

引入（設計模式）後雖然做到了高度的解耦，------設計模式不是為了解耦，解耦只是帶來的效果，關鍵是清晰的功能分割，容易擴展。但基本不變的東西，或者本來就是耦合的東西就不需要引入一些模式。

但是代碼邏輯複雜了，怎麼平衡好？-----我問你，加法複雜還是乘法複雜，微積分呢，人們有了加法為何還要發明乘法這樣複雜的東西? 從1加到N 你願意一個一個加起來得出結果，還是用(1+n)*n/2直接得出結果？

不要把自己停留在小學生水平，覺得初高中的東西複雜，那樣你永遠只能做小學生的題。到了初中，乘法就是小孩子遊戲，根本不需要特別注意什麼時候用乘法，到了大學生水平，知道什麼時候該用微積分，簡單的方程是再顯然不過的事情。該用什麼數學工具就用什麼數學工具。

從 @陳碩的發言和鏈接中獲益良多，近一年來我被過度設計過度傷害了

談談我的看法吧，歡迎拍磚。

首先從語言層面來說，Java語言比C++語言封裝得更好，比較純粹的面向對象語法和一套標準的開發庫，大大簡化了開發的難度。而C++語言比較底層，再加上它需要對C保持兼容，導致使用C++語言做開發時，對以前使用C開發，剛剛轉入C++沒幾年的人，很難把思路從面向過程轉向面向對象上來，這是我在實際工作中常常看到的現象，例如頻繁的使用單例模式，習慣使用printf, sprintf，習慣使用FILE和宏，參數全部使用指針等等。不過，這裡無意引起一個老套的爭論，C++好還是Java好，或者面向對象好還是面向過程好。我個人的觀點是，任何一種計算機語言都有解決問題的能力，針對不同的項目，不同的問題域，甚至是針對個人習慣，採用哪種語言都行。說句極端的話，你要使用腳本如JavaScript, Python, Ruby來開發，只要你寫得好，也是可以的。區別可能只是在於具體到某個項目上值不值得，或者可不可行的問題。

其次，我們碼農做程序開發，有一個很大的誤區，認為某項特定的技術（如設計模式、C++模版、多線程技術）能夠解決所有的問題。有一句話是這樣形容的，「手裡有一把鎚子，看哪裡都有釘子」。尤其是剛剛學習到的知識，總是有一股衝動，一有機會就想去使用它。說實話，本人也是如此。但是，從軟體項目的角度來看，這種做法是十分有害的，這裡就不展開談了（時間太晚了Zzzzzz....)。

想要對業務邏輯解耦，必須對代碼進行進一步的抽象，但是並不意味這抽象程度越高，代碼邏輯就會變得複雜，也不意味著代碼越來越難讀。代碼的複雜程度應該和業務邏輯的複雜程度有一個正比的關係。只有需求複雜度上去了，代碼才應該越來越複雜。為了抽象而抽象，為了解耦而解耦是沒有意義的。

總之一句話，代碼複雜，抽象程度高，並不意味著你的代碼就理所當然的難以理解，變得很難讀。關鍵還是在於設計功力和編碼功力。

引入設計模式後：

局部看，代碼邏輯複雜了；

全局看，系統結構清晰了。

當然，好東西容易被濫用，那就另說了~

設計模式主要用在溝通上。基本要求是：整個團隊都要理解該模式，這樣大家一看代碼風格就猜到真正的邏輯代碼在哪個文件哪個類哪個函數里。函數間的互相刁用邏輯也比較清楚。便於溝通。

如果僅僅是自己設計或者小團隊或者長期共事的團隊，我們往往都是按自己的設計方式設計，不一定完全符合設計模式描述的那樣。只要便於理解、溝通，代碼好維護，沒有邏輯性上的設計錯誤。

寫代碼也寫了很久，漸漸有種感悟，有時候真正好的代碼即高度的解耦，效率又非常高，比如C++的模板，用好了就是神器。這是我們所追求的，如果實在達不到，我傾向於用更加有「設計」意味的代碼，因為修改維護理解起來快，另外一個原因也是，沒有完善的性能測試，我們往往並不清楚系統真正的性能瓶頸在哪。而結構清晰的代碼會幫助我們更好的優化代碼。

設計模式是站在宏觀角度對整個系統架構進行設計的，良好的設計模式可以使代碼宏觀上架構更清晰、更簡潔、更魯棒，關鍵在於設計者的功底

引入設計模式，代碼的邏輯一定會變複雜了嗎？

設計模式，能否發揮價值，還要看整個團隊是否都能認同，並且掌握。

代碼是寫給入看的，人不爽了，就會破壞結構，最終導致無法維護。

模式也是為了統一風格，關鍵還是看團隊是否能達成一致標準，提高代碼質量。

「但是代碼邏輯複雜了」又不是什麼缺點，關鍵寫出可復用性強而質量高的代碼。

要說到平衡的話，項目進度會有一個壓力，會影響到代碼質量吧。不過從長遠看，質量高的代碼還是降低成本的。

對於喜歡c的來說，模式太複雜了

不是複雜，是你看不懂