類內部結構

類內部架構實際上是一個小型的狀態機，成員變量是狀態變量，成員函數是處理機。一般提倡一個類實現一種特定的功能，這樣可以降低實現的復雜性，狀態機越簡單，越利于實現。

實例間通信

軟件的功能是多個模塊共同協作來實現的。這就需要多個模塊的實例進行通信、相互調用。
相互調用和訪問對類或模塊來說，就是設計對外接口。這也是public、private關鍵字的設計思想。

對外接口數量越少，每個模塊間的耦合越少，代碼維護起來越簡單；反之，模塊間交互越多，耦合性越高，軟件維護難度越高。

對于開發人員來說，類或者模塊實例間的相互訪問，要求程序員控制好實例的可見性。如果控制不好，軟件后期的維護難度會增加。

實例可見性管理

實例可見性管理分為實例生命周期管理和實例訪問路徑管理兩個方面。

實例生命周期管理

每個實例都有生命周期，生命周期是軟件開發人員可以控制的。例如基本類型的變量只能存在于作用域內，超出作用域其保存的數據就會失效。實例也一樣，實例只有在生存期內才可以被訪問。這是一切訪問的前提。
生命周期管理，即要求軟件開發人員正確分配實例存活時間。

• 如果實例存活時間太短，會導致找不到此實例，無法實現預期功能。
• 如果實例存活時間太長，會持續占用內存等資源，造成資源利用率低。例如將所有實例采用全局變量保存，優點是此實例在整個軟件運行時間，任何模塊都能訪問，缺點是這樣的軟件資源消耗會很嚴重。

實例訪問路徑管理

訪問途徑和實例的嵌套程度有關。
例如，全局實例、可全局訪問的單例、位于全局實例內的實例（半全局）可以通過最多一次函數調用獲取到實例地址。而對于嵌套的類來說，嵌套的層數即獲取實例地址需要間接尋址或函數調用的次數。顯然，訪問路徑越簡單，需要編寫的代碼越少，開發和運行效率也越高。
所以最簡單的路徑還是全局的或半全局的，并且在軟件設計中，減少類嵌套，簡化訪問路徑。

例如，你現在參與一個已在開發中的項目后，為了添加一個需求，你需要訪問一些已有的實例數據。你可能會遇到暫時獲取不到目標實例指針的問題，這就需要你自己添加獲取目標實例指針的代碼，或者調整代碼結構，這無疑是不少的工作量。但是對客戶來說，明明窗口都在那擺著，直接一句話訪問不就行了嗎？而客戶卻不知道你為了修改一個功能，要考慮如何更好的管理實例生命周期。最后的結果是加班或者拖延項目進度。
從上面的例子可知，已有的代碼可以幫助你，也可以讓你發瘋。

實例可見性管理是會隨著需求的改變而需要動態調整的。例如有的變量本來只需要在內部訪問，在需求改變后，需要在幾個模塊間共享，這就需要對其可見性進行修改。

正因為可見性管理是會隨需求改變而改變的，所以在實際開發中，可以將其生命周期設置得靈活一點，或者留有一些余量，以便于對未來的改變做較少的調整。

有一種比較松散的實例管理方式。每種實例設置一個全局的管理器，多個相關實例具有相同的id。根據其中一種數據，查找相關數據時，只需要用同一個id去查找。一個實例銷毀，不影響其他實例，可以自由控制實例的生存時間。

量化

如果將實例的訪問管理交給軟件開發者管理，會增加軟件開發者的負擔，同時也因為軟件開發者能力或項目預算等因素導致軟件的開發、維護工作量不穩定，降低軟件質量。

所以如果可以將實例的訪問管理進行量化，讓所有的需要交互的實例（即相對非內部的實例或數據）均為全局、半全局實例，在開發完成后進行自動優化，及時釋放資源未被使用的資源，這就會減輕軟件開發者的負擔，提高開發效率，最終有更多的時間去減少bug，優化交互等等，從而提升軟件質量。

總結

本文主要介紹了使用面向對象的方法開發軟件時，程序中對象協作方式與實例管理相關內容，為了寫出更好的軟件，可以參考上述內容考慮代碼的組織結構。

總結

以上是生活随笔為你收集整理的面向对象软件开发代码结构（1）的全部內容，希望文章能夠幫你解決所遇到的問題。

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