請允許我在描述調用返回風格之前，先講一個短小的故事。調用返回風格是在程序發展的道路上逐漸演變而來的。最初的程序設計風格，叫非結構化程序設計，是歷史上最早的能夠創造圖靈完備算法的程序設計模式。
非結構化編程的樣式
由是，結構化編程應運而生。它背后是由結構化程序定理來支持的，我們先來了解一下。
結構化程序定理：只要一種編程語言可以依三個方式組合其子程序及調整控制流程，則每個可計算函數都可以用此種編程語言來表示（實現任何算法）。三個調整控制流程的方式為：
- 序列結構：按照順序執行一個子程序，然后再執行另一個子程序
- 選擇結構：根據布爾表達式的值，執行兩個子程序中的一個子程序（if, else if, else）；
- 迭代結構(for, while)：執行子程序，直到一個布爾表達式為true
序列結構 選擇結構 循環結構
我們可以看出如下幾點：
- 該定理強調使用子程序、塊狀結構和for和while循環；而不是使用簡單測試后再使用跳躍語句，例如goto語句；
- 該定理保證了只要一種編程語言支持序列結構、選擇結構、循環結構(而不必使用goto語句語句)，則可以實現任何可計算函數；
- 該定理是結構化編程的理論基礎。
好了，現在開始進入正題。調用返回架構有幾個典型的風格，分別是主程序-子程序風格和面向對象系統風格。下面我們來一一說明。
1、 主程序-子程序風格
顧名思義，它的內容就是在主程序中調用多個子程序，也就是我們常用的main函數。其中子程序還可以調用它自己的子程序，這樣下來就構成一棵程序樹。
程序結構示意圖（其中每個箭頭代表一次調用）
顯而易見，它的構成組件是主程序和子程序，連接件是調用-返回機制，而拓撲結構則是層次化結構。
那怎么在實際中運用這個架構呢？結果也是簡單明晰的，對於這樣一個自頂向下一次到位的龐然大物，我們首先要知道整個程序中各數據的走向，所以要先畫出DFD圖；然后根據數據流動設計子程序部分，這樣可以畫出程序結構示意圖（如上圖）；接下來就是看一看這個圖究竟畫得合不合理，是不是有需要改進的地方，評估一下；最后萬事俱備只欠東風，就要准備寫代碼啦！
舉個栗子🌰吧。
現在我們有一家醫葯公司，很賺錢的哦，然而賺多少錢還是取決於研發了什么葯物。研發葯物的投資也是非常大的，不能亂投，作為老總的你當然很想知道研發什么葯品生產之后才能最賺錢，自己又懶得算（我就不信有人勤快算！），就想找程序員寫一個程序計算每種葯品的單位成本，通過輸入葯品名稱來知道它研究的費用和生產的費用。
首先讓我們進行第一步，畫數據流圖。這里給出前三層的數據流圖作為參考。
第0層DFD
第1層DFD
第2層DFD
畫到這里，程序的邏輯就基本清晰了。那么讓我們愉快的把它翻譯成程序結構圖吧：）
好了，現在我們回頭來審視一下這個東西。看起來沒毛病。可以拿着它們去交差了！（如果忽略代碼實現的話）
這個風格到這里就結束了。讓我們來回顧一下。
主程序-子程序的出現在編程史上無疑是一座里程碑。它有效地將一個較復雜的程序系統設計任務分解成許多易於控制和處理的子任務，便於開發和維護，尤其在較大規模的程序設計上完全取代了非結構化編程，是一個成功的設計方法。然而主程序的正確性會受到所有子程序的影響，可謂牽一發而動全身。當程序規模過大，比如超過十萬行的時候，運用它並不是一個明智的選擇，因為邏輯繁復復雜，開發和測試上也都會遇到困難，它會變得特別慢並且錯誤百出。此外，它的可重用性幾乎沒有，可維護性也比較差，這意味着每一次需求變更都要修改大片大片的代碼，而每一次接到任務都是一次全新的開發——哦，那可真是太糟糕了，我仿佛看到了一萬個小時的無償加班。還有一點無法忽略，就是圖形用戶界面的程序和所有需要實時交互的系統都很難用過程來描述，這就意味着難以開發和維護大型軟件和圖形界面的應用軟件，從而被大眾群體所接受。漏了一點（它怎么這么多缺點），由於對過程的着重關注，它忽略了對數據的控制，數據安全性一類屬性也比較差。
它的優缺點都是比較明顯的，使用時可以酌情考慮。
2、面向對象設計方法（Object-Oriented Design，OOD）
面向對象，顧名思義，就是關注對象之間交互的一種設計方法。什么是對象呢？從小花小草，到字符數組，凡是具有自身特定屬性和自主行為的事物都可以被抽象為類，我們說這個對象就是當前類的一個實例化。在這個方法中，我們只關心對象和對象之間的交互，即只存在一個對象調用另一個對象的情況。
老虎的類定義
顯而易見，它的構成組件是類和對象，連接件是對象之間的函數調用。
面向對象我不想講太多（才不承認不是很會），學到體系結構的應該至少會一門面向對象語言，這里就略過好了😝。
好，我們來總結一下。
OOD風格優點
§易維護和復用
–因為對象對其它對象隱藏它的表示（數據和操作），所以可以改變一個對象的表示，而不影響其它的對象
–類本身具有非常良好的可重用性，繼承和封裝方法為對象復用提供了技術支持
–組件之間依賴性降低，高內聚低耦合
§反映現實世界，是現實世界的一個映射，通俗易懂
§容易分解一個系統
–設計者可將一些數據存取操作的問題分解成一些交互的代理程序的集合
OOD風格缺點
§管理大量的對象：應該怎樣確立大量對象的結構？
§繼承會大量提升復雜度，關鍵系統中一定要慎用
§必須知道對象的身份
–為了使一個對象和另一個對象通過過程調用等進行交互，必須知道對象的標識。只要一個對象的標識改變了，就必須修改所有其他明確顯式調用它的對象，並消除由此帶來的一些副作用(例如，如果A使用了對象B，C也使用了對象B，那么，C對B的使用所造成的對A的影響可能是料想不到的)
§不是特別適合功能的擴展。為了增加新功能，要么修改已有的模塊，要么就加入新的模塊，從而影響性能
3、主程序-子程序和OOD之間的比較
前者關注系統對功能性函數的分解，程序由有一定順序的函數集合構成。
后者關注系統對對象的抽象，程序主要依賴於數據（屬性和方法）。