現實編程（概述）

編寫程序爲了完成現實的功能，爲了可以編寫出更好的代碼，開發人員不斷地進行抽象，提取，複用，而且在此基礎上設計個優良的軟件架構。

通常的軟件設計認爲系統是總體的，耦合的，因此設計的思路是在現實需求的基礎上進行一些提取，將功能點進行抽象，從而達到解耦和模塊化的目的。

現實編程偏偏相反，認爲系統是自己就是模塊的，解耦的，所以設計的思路也不一樣，並不刻意要求去進行抽象，而是儘量的用軟件去描述系統自己，不少時候不是進行向上的抽像，而是向下的分解。

現實編程的好處是可以將需求快速轉化爲可用的軟件，同時可以得到一個不錯的軟件架構——高內聚低耦合的系統，具備較好的可拓展性和可維護性。

現實編程之因此速度快是由於不須要花多大的時間進行設計，甚至不須要進行設計。在時候有你甚至能夠直接進行編程，而不須要先設計出一個基本的框架， 這在那些需求不明確，頻繁變化的系統開發中頗有價值。

系統的需求越貼近現實世界，這種方法的效果越好，反之效果越差。

 

通常經常使用的軟件設計思路是這樣的：

 

1. 當咱們拿到原始需求之後進過度析，將整個需求分解成多個小的需求。
2. 從小的需求中提取抽象，劃分紅多個功能塊。
3. 根據這些功能塊劃分出軟件須要的模塊。
4. 根據整個軟件的架構優化模塊，直到軟件架構的成型。

 

 請注意，上圖中的需求，功能和模塊之間的連線使用的虛線，這說明它們並非一一對應的，它們的關係是多對多的關係。

 舉個例子來講，咱們須要製做一個貪吃蛇遊戲。

通常的思路能夠畫出以下的圖：

 

根據這張圖你會設計出對應的類，設計好每一個類的交互方式，最後設計出一個完整的系統。

它是能夠工做的，若是後續的需求可以按照你設計的方向來變化的話，它應該具有不錯的拓展性。不過不幸的是，需求的變化每每超出咱們預想的範圍。系統第一個版本出來之後，原有的架構會在各類各樣的需求的變化過程當中不斷地腐化。

 

現實編程的思路與之不一樣，現實編程使用代碼儘量地描述真實的事物，並以此爲依據完成軟件的設計。

 

 

 注意上面圖中的模塊不是咱們隨意想象出來的，而是現實中實際存在的劃分。

對於貪食蛇來講，系統的圖劃分以下

 

 

咱們能夠看到，全部的模塊都不是咱們本身杜撰出來的，而是對真實的事物進行的分解。這樣功能天然而然的被分配到每一個模塊中。

 

現實編程的好處：

• 可以使軟件架構模塊自然的解耦。前面提到，現實編程認爲系統自己就是解耦的。在現實世界中，全部的事物均可以相互影響，同時卻又保持了徹底的獨立。好比說，一我的能夠和周圍的一切事物相互影響——人，空氣，陽光，水等等，可是同時人卻又是一個徹底的獨立的個體。這就比如是軟件中的模塊，既要和其餘的模塊進行交互，同時又要保持本身的獨立性。架構師們費盡心思想要的實現的高內聚，低耦合。在現實世界倒是常見的現象。因此咱們不是抽象現實，而是模擬現實。
• 更加容易實現的設計。開發人員常常會遇到一個問題，這個類放到哪一個模塊？這個功能放到那個類？這個方法應該對外暴露嗎？這樣的問題在至始至終就困擾着全部人。同時使人遺憾的是，人們老是在這樣的問題上作出了錯誤的決定。因此，想象現實中的系統是怎麼實現的？它有這個功能嗎？它是怎麼交互的？模擬它，會讓咱們減小不少的麻煩。
• 更好的可讀性的代碼。在軟件中常常會看到各類各樣的抽象類。好比說XXXManager，XXXHelper等。這些類可以幫助咱們更加容易的實現功能，可是若是數量過多的話就會變成一場災難。它會讓代碼的可讀性變得很是差，架構變得異常複雜，難以維護。現實編程中這種類會變得很是的少。
• 更快的開發速度。減小了設計時間同時又能擁有一個自然解耦的架構，開發速度天然會提升很多。