人天生就是審美家，軟體工程師在設計和編寫程式時這種天性會自然的發揮作用，但其作用很有可能被忽視。筆者在做軟體設計時，會不時出現讓自己也覺得彆扭的情形，在這種情形下筆者知道是審美的天性在發出告警，「hey，man！這樣的設計好象不是很好哦！」。一旦出現「審美告警」，筆者通常都是停下手中的工作，去與同事聊聊天、或是倒杯水喝什麼的。當然，雖然在做別的事，但腦中還是會潛在地思考什麼地方不對。有時在很短的時間內就會找回感覺，並發現設計中應當改進的地方，直到「審美告警」消失。偶爾，消除「審美告警」得花上
二、三天的時間，但這些時間的花費最終都有回報，可能思考花了
二、三天，但編寫**一天就完成了。那為什麼做工作時不能只花最後一天編碼的時間呢？這讓作者想到了「第七個餅」這一故事。
或許有的讀者一看到這就在想，「我們的專案時間很緊，哪有時間去關心 『審美告警』啊！」。表面上，不關心「審美告警」能節約時間，但卻未必真的就是這樣。就筆者的個人經驗來看，如果做設計時覺得彆扭，那工作效率一定不好；反之，一旦自己覺得「這個設計就應當是這樣的」則工作效率奇高。其實，軟體設計真正花時間的是思考，而不是編碼。沒有思考清楚的話，做得越多可能要糾正一其中的不足所花費的時間也越多。思考的目的是什麼？是從紛繁的現象中試圖找到問題的本質，或者從眾多的因素中找出關鍵。設計時之所以會覺得彆扭，一定是有什麼沒有考慮清楚，抑或命名不貼切、多考慮了什麼等。這種情形下停下來做進一步的思考將有助於理清思路，從而最強終做出更好的設計。
「審美告警」資訊的強弱與軟體工程師的設計水平可能是正相關的，筆者相信每個軟體工程師或多或少都能感覺到它。軟體工程師如果重視這種訊號，則這種訊號的靈敏度也會慢慢提高。因為重視它意味著將做更多的思考，而思考多了就更容易形成自己的原則，進而這些原則在設計過程中將發揮作用。相反，如果長期忽視它的存在，則最終可能會造成這種訊號的消失，或出現紊亂。忽視這種訊號的存在，或許意味著我們並不關心所設計的主題，其質量也別指望好到哪去，更有甚者會醞釀出將來的乙個「毒瘤」。
設計模式的設計原則
單一職責原則 srp 單一職責適用於 介面，類，方法 開放封閉原則 ocp 乙個軟體實體應當對外擴充套件開放，對修改關閉 關鍵 什麼叫做鉤子方法？是對於抽象方法或者介面中定義的方法的乙個空實現 在實際的運用中，例如有乙個介面，這個介面裡面有7個方法，而你只想用其中的乙個方法，那麼這時，你可以寫乙個抽...
設計原則與思想 設計原則
如何理解單一職責原則 srp solid原則並非單純的1個原則,而是由5個設計原則組成,他們分別是 單一職責原則,開閉原則,裡式替換原則,介面隔離原則和依賴反轉原則,依次對應solid中的s,o,l,i,d這五個英文本母 單一職責原則的英文是single responsibility princip...
物件導向的設計原則 類設計原則
物件導向設計中，如何通過很小的設計改變就可以應對設計需求的變化，這是令設計者極為關注的問題。為此不少oo先驅提出了很多有關物件導向的設計原則用於指導oo的設計和開發。下面是幾條與類設計相關的設計原則。1.開閉原則 the open closed principle ocp 乙個模組在擴充套件性方面應...