編寫程序為了完成現實的功能，為了能夠編寫出更好的代碼，開發人員不斷地進行抽象，提取，復用，並且在此基礎上設計個優良的軟件架構。
一般的軟件設計認為系統是整體的，耦合的，所以設計的思路是在現實需求的基礎上進行一些提取，將功能點進行抽象，從而達到解耦和模塊化的目的。
現實編程恰恰相反，認為系統是本身就是模塊的，解耦的，因此設計的思路也不同，並不刻意要求去進行抽象，而是盡可能的用軟件去描述系統本身，很多時候不是進行向上的抽像，而是向下的分解。
現實編程的好處是能夠將需求快速轉化為可用的軟件，同時能夠獲得一個不錯的軟件架構——高內聚低耦合的系統，具有較好的可拓展性和可維護性。
現實編程之所以速度快是因為不需要花多大的時間進行設計，甚至不需要進行設計。在時候有你甚至可以直接進行編程，而不需要先設計出一個基本的框架， 這在那些需求不明確，頻繁變化的系統開發中很有價值。
系統的需求越貼近現實世界，這種方法的效果越好，反之效果越差。
一般常用的軟件設計思路是這樣的：
- 當我們拿到原始需求以后進過分析，將整個需求分解成多個小的需求。
- 從小的需求中提取抽象，划分成多個功能塊。
- 根據這些功能塊划分出軟件需要的模塊。
- 根據整個軟件的架構優化模塊，直到軟件架構的成型。
請注意，上圖中的需求，功能和模塊之間的連線使用的虛線，這說明它們並不是一一對應的，它們的關系是多對多的關系。
舉個例子來說，我們需要制作一個貪吃蛇游戲。
一般的思路可以畫出如下的圖：
根據這張圖你會設計出對應的類，設計好每個類的交互方式，最后設計出一個完整的系統。
它是可以工作的，如果后續的需求能夠按照你設計的方向來變化的話，它應該具備不錯的拓展性。不過不幸的是，需求的變化往往超出我們預想的范圍。系統第一個版本出來以后，原有的架構會在各種各樣的需求的變化過程中不斷地腐化。
現實編程的思路與之不同，現實編程使用代碼盡可能地描述真實的事物，並以此為依據完成軟件的設計。
注意上面圖中的模塊不是我們隨意想象出來的，而是現實中實際存在的划分。
對於貪食蛇來說，系統的圖划分如下
我們可以看到，所有的模塊都不是我們自己杜撰出來的，而是對真實的事物進行的分解。這樣功能自然而然的被分配到每個模塊中。
現實編程的好處：
- 能夠使軟件架構模塊天然的解耦。前面提到，現實編程認為系統本身就是解耦的。在現實世界中，所有的事物都可以相互影響，同時卻又保持了完全的獨立。比如說，一個人可以和周圍的一切事物相互影響——人，空氣，陽光，水等等，但是同時人卻又是一個完全的獨立的個體。這就好比是軟件中的模塊，既要和其他的模塊進行交互，同時又要保持自己的獨立性。架構師們費盡心思想要的實現的高內聚，低耦合。在現實世界卻是常見的現象。所以我們不是抽象現實，而是模擬現實。
- 更加容易實現的設計。開發人員經常會遇到一個問題，這個類放到哪個模塊？這個功能放到那個類？這個方法應該對外暴露嗎？這樣的問題在至始至終就困擾着所有人。同時令人遺憾的是，人們總是在這樣的問題上做出了錯誤的決定。所以，想象現實中的系統是怎么實現的？它有這個功能嗎？它是怎么交互的？模擬它，會讓我們減少很多的麻煩。
- 更好的可讀性的代碼。在軟件中經常會看到各種各樣的抽象類。比如說XXXManager，XXXHelper等。這些類能夠幫助我們更加容易的實現功能，但是如果數量過多的話就會變成一場災難。它會讓代碼的可讀性變得非常差，架構變得異常復雜，難以維護。現實編程中這種類會變得非常的少。
- 更快的開發速度。減少了設計時間同時又能擁有一個天然解耦的架構，開發速度自然會提高不少。