來自coolshell

?

不過這些原則看上去都不難，但是要用好卻并不那么容易。要能把這些原則用得好用得精，而不教條，我的經驗如下：（我以為這是一個理論到應用的過程）

你可以先粗淺或是表面地知道這些原則。

但不要急著馬上就使用。

在工作學習中觀察和總結別人或自己的設計。

再回過頭來了回顧一下這些原則，相信你會有一些自己的心得。

有適度地去實踐一下。

Goto第?3步。

?

?

You Ain’t Gonna Need It (YAGNI)

這個原則簡而言之為——只考慮和設計必須的功能，避免過度設計。只實現目前需要的功能，在以后您需要更多功能時，可以再進行添加。

• 如無必要，勿增復雜性。
• 軟件開發(fā)先是一場溝通博弈。

以前本站有一篇關于過度重構的文章，這個示例就是這個原則的反例。而，WebSphere的設計者就表示過他過度設計了這個產品。我們的程序員或是架構師在設計系統(tǒng)的時候，會考慮很多擴展性的東西，導致在架構與設計方面使用了大量折衷，最后導致項目失敗。這是個令人感到諷刺的教訓，因為本來希望盡可能延長項目的生命周期，結果反而縮短了生命周期。

參考：http://en.wikipedia.org/wiki/You_Ain%27t_Gonna_Need_It

Law of Demeter?– 迪米特法則

迪米特法則(Law of Demeter)，又稱“最少知識原則”（Principle of Least Knowledge），其來源于1987年荷蘭大學的一個叫做Demeter的項目。Craig Larman把Law of Demeter又稱作“不要和陌生人說話”。在《程序員修煉之道》中講LoD的那一章叫作“解耦合與迪米特法則”。關于迪米特法則有一些很形象的比喻：

• 如果你想讓你的狗跑的話，你會對狗狗說還是對四條狗腿說？
• 如果你去店里買東西，你會把錢交給店員，還是會把錢包交給店員讓他自己拿？

和狗的四肢說話？讓店員自己從錢包里拿錢？這聽起來有點荒唐，不過在我們的代碼里這幾乎是見怪不怪的事情了。

對于LoD，正式的表述如下：

對于對象 ‘O’ 中一個方法’M'，M應該只能夠訪問以下對象中的方法：

對象O；

與O直接相關的Component Object；

由方法M創(chuàng)建或者實例化的對象；

作為方法M的參數的對象。

在《Clean Code》一書中，有一段Apache framework中的一段違反了LoD的代碼：

final String outputDir = ctxt.getOptions().getScratchDir().getAbsolutePath();

這么長的一串對其它對象的細節(jié)，以及細節(jié)的細節(jié)，細節(jié)的細節(jié)的細節(jié)……的調用，增加了耦合，使得代碼結構復雜、僵化，難以擴展和維護。

在《重構》一書中的代碼的環(huán)味道中有一種叫做“Feature Envy”(依戀情結），形象的描述了一種違反了LoC的情況。Feature Envy就是說一個對象對其它對象的內容更有興趣，也就是說老是羨慕別的對象的成員、結構或者功能，大老遠的調用人家的東西。這樣的結構顯然是不合理的。 我們的程序應該寫得比較“害羞”。不能像前面例子中的那個不把自己當外人的店員一樣，拿過客人的錢包自己把錢拿出來。“害羞”的程序只和自己最近的朋友交 談。這種情況下應該調整程序的結構，讓那個對象自己擁有它羨慕的feature，或者使用合理的設計模式（例如Facade和Mediator）。

參考：http://en.wikipedia.org/wiki/Principle_of_Least_Knowledge

?

?

?

轉載于:https://www.cnblogs.com/taoxu0903/archive/2011/04/27/2030767.html

總結

以上是生活随笔為你收集整理的[摘抄]一些软件设计的原则的全部內容，希望文章能夠幫你解決所遇到的問題。

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