班級如何幫助您管理大型應用程序？

Question

這出現在我正在上網的一次對話中，我發現我不知道這應該如何工作：很多程序員似乎只是把它當作給定 - 實際上，很明顯，類是一個必要的語言功能來管理大型軟件項目。

我不明白他們是如何做到這一點的。

我對你的問題是，你怎麼知道的？那裏有什麼客觀的措施表明類可以提高生產力，代碼重用和降低程序生產的複雜性？課程的哪些方面使他們成爲大型團隊協作的理想之選？

現在，我想問一個問題，這有點難以表達。我很抱歉，如果我得到這個錯誤，並最終混淆或憤怒任何人：

客觀地說，你怎麼知道類的使用不是應用程序的大原因開始？也就是說，是否可以編寫一個功能相當的程序，使用其他代碼重用策略，使用少得多的代碼，足夠小，不需要任何特殊措施來「管理」它？ （有很多選擇，如功能性編程範例或面向方面的編程）。

最後一點是Steve Yegge在他的博客上暗示的。但是，由於真正缺乏來自任何人的任何硬性數據，而且沒有足夠的經驗來自行得出結論，所以我對這個論證的雙方都持懷疑態度。

您認爲如何？

編輯：特別是我感興趣的是，爲什麼很多程序員認爲原型風格繼承在大型應用程序方面沒有完成任務。我很抱歉，這個問題很模糊 - 這是我對這個主題缺乏瞭解的產物。

edit2：似乎有什麼困惑我的意思是功能編程。 （我不認爲VB的任何版本都有功能，當然不是老版本）。請參閱維基百科文章。 http://en.wikipedia.org/wiki/Functional_programming

edit3：讓我強調我正在尋找客觀的措施。不是主觀意見。

Answer 1

封裝理論爲類的優越性提供了一個客觀的理由。

國際標準化組織將封裝定義爲「對象中包含的信息只能通過對象支持的接口進行交互才能訪問的屬性」。

因此，由於可以通過這些接口訪問某些信息，因此某些信息必須在對象內隱藏且無法訪問。這種信息展示的財產被稱爲信息隱藏，Parnas認爲模塊應該被設計爲隱藏可能改變的困難決策和決策。

請注意，單詞：改變。信息隱藏涉及潛在的事件，例如未來難以改變的設計決策。

考慮一個包含兩個方法的類：方法a（）是隱藏在類中的信息，方法b（）是公共的，因此可以被其他類直接訪問。

對方法a（）的未來更改有一定的可能性需要對其他類中的方法進行更改。對方法b（）的未來變化也需要改變其他類中的方法。然而，方法a（）會出現這種紋波變化的概率通常會低於方法b（），因爲方法b（）可能依賴於更多的類。

這減少了紋波影響的可能性是封裝的關鍵好處。

考慮任何程序中源代碼依賴項的最大潛在數量（MPE - 首字母縮略詞來自圖論）。從上面的定義推斷，我們可以說，鑑於兩個程序爲用戶提供相同的功能，具有最低MPE的程序被更好地封裝，並且從統計上講，更好地封裝的程序將更便宜地維護和開發，因爲成本的最大潛在變化將低於不太好囊括的系統的最大潛在變化。

此外，還要考慮一種只有方法而沒有類的語言，因此沒有方法可以相互隱藏信息。假設我們的程序有1000個方法。這個計劃的MPE是什麼？封裝理論告訴我們，給定一個n個公共節點的系統，這個系統的MPE是n（n-1）。因此，我們的1000種公共方法的MPE是999,000。

現在讓我們把這個系統分成兩個類，每個類有500個方法。因爲我們現在有課程，所以我們可以選擇公開某些方法並且私有方法。這將是這種情況，除非每種方法實際上都依賴於其他方法（這不太可能）。假設每個班級有50種方法是公開的。系統的MPE是什麼？封裝理論告訴我們它是：n（（n/r）-1 +（r-1）p）其中r是類的數量，p是每個類的公共方法的數量。這將使我們的兩級系統的MPE達到499,000。因此，這種兩級系統變化的最大潛在成本已經遠遠低於未包封系統的成本。

假設你將你的系統分爲三個類，每個類有333個類（好的，一個將有334個），每個類都有50個公共方法。什麼是MPE？再次使用上述公式，MPE約爲482,000。

如果systém分爲4類250個方法，MPE將是449,000。

如果在我們的系統中增加類的數量總是會減少MPE，但事實並非如此。封裝理論表明，爲了使MPE最小化，系統應該被分解到的類的數量是：r = sqrt（n/p），對於我們的系統來說，它實際上是4個。例如，具有6個類的系統將具有MPE 465,666。

Answer 2

我對任何編程範例都沒有太大的偏見，但我一直以OO的方式運作一段時間。

就我個人而言，我有很多'a-HA！'類的直接幫助我瞭解我工作得更好的領域。

最值得注意的是，在對系統出現故障或系統應該做什麼感到困惑的情況下，班級經常會迫使我去思考這個整體應該做什麼，以及更多往往不會導致重構當前的類/方法。

總之，封裝真的讓我更開心。 ;）

希望有所幫助。

Answer 3

我更喜歡類，因此我可以將一個大問題劃分爲可作爲單個單元進行測試的可管理片段。恕我直言，代碼重用被高估 - 我幾乎沒有看到它發生在我工作的地方。對我而言，我從最佳OO中獲得的最好的可測試性。

另一個極端是使用一堆全局變量，並在public static void main（或Page_Load在ASP.NET中）中包含所有邏輯，並調用調用其他靜態方法的靜態方法，等等......（我頭暈目眩）

唯一會打破我的面向對象思維的是如果我正在使用純粹的函數式語言，這是我自從大學以來沒有想過的東西。

Answer 4

這是一個非常好的問題。將代碼組織到類中是開發團隊創建小型可重用模塊的一種方式。此外，這些模塊具有表達性和有限的接口，只表示類能夠做什麼，而不表示它如何做。每個類別與其他類別都是正交的，因此在出現錯誤時是高度可測試和模塊化的。

現在我剛剛描述的是來自完美世界的奇怪場景。但是任何做OOP工作的優秀開發人員都應該努力爭取這樣的東西。

面向對象是一個承認，我們，開發人員，只是人爲的，不能同時理解整個系統。因此，我們將系統分解成可重複使用的小部件並專注於這些部件。

以美國的十位數電話號碼爲例。很難記住你頭上的十位數字，所以我們做心理學家稱之爲「組塊」的東西。這意味着我們在精神上將數字分解成我們可以更好記住的塊。因此1234567890變成123-456-7890。對我們來說幸運的是，電話公司也以相同的方式打破了這些數字，並指定了大塊的含義。 123是區號，456是前綴，而7890是行號。每個塊都像一個類，它們都有各自的責任，格式和含義。

所以總而言之，我所能說的最好的事情是，OOP允許我們構建具有集中和封裝功能的大型可擴展系統。它使我們不必總是看到大局，並能夠專注於做一件事並做得好。

Answer 5

兩件事。

第一個想法是一個類是不透明的域實體。 當正確完成時，面向對象的程序引入了一個抽象層：在下一個最高層，你編組對象來做你想做的事情，而不是處理細節。你不需要知道對象和類是如何工作的，只需要知道它們是如何工作的。這是一種信息隱藏，它減少了團隊在工作時必須保持頭腦的複雜性。第二種是面向對象編程允許重用一種代碼：您可以定義重寫其他類中的某些行爲的類（繼承），或其實例包含其他類的實例的類，使用它們實現其目標（包封和組成）。

正確使用面向對象技術可以減少需要管理的代碼量，並減少在工作或維護系統時需要記住的事項數量。實際上，這種方法並不總是奏效。

Answer 6

我覺得類可以提供幫助，因爲它們對應於categorization這個非常普遍的認知概念，所以可以幫助自然地描述大型應用程序。

Answer 7

客觀地說，你怎麼知道 使用類是不 應用是大開始的原因是什麼？

拿，這不是面嚮對象語言編寫的任何大型程序/應用程序（如C，COBOL，甚至普通的SQL），你應該能夠看到該代碼大小並不直接歸因於語言範式。對於每一個精心設計的，高度精煉的，可重用的C＃或Java組件，還有相同數量的精心設計的，高度精煉的，可重用的C DLL。相反，有相同數量的可怕的，臃腫的代碼。

問題是，好的程序員能夠改進他們的系統設計，而不管語言/平臺。

關於OOP，至少對我來說，它帶來了一個「潛力」 - 編程世界的一個視圖高舉到我們的現實世界。我們都知道我們的世界，這個宇宙的物質充滿了由較小的物體組成的物體。一直保持從星系星系到分子，原子和亞原子粒子的放大，真正令人驚奇的是，以各種不同的模式組合相同的微小粒子，形成了巨大的差異。甚至可以看看我們自己的生物學，有時候我們認爲60％的身體在分解到最好的時候實際上只是水，這是令人難以置信的。然而，看看所有各種系統和器官的化學燃燒，以保持我們的運行和活着。

當我們學會了解構成我們在日常自然中看到的真實世界系統的構建塊的簡單性（哦，真的......哈哈）時，我們應該能夠理解設計和構建非常複雜或複雜的系統應該從自己做得很少的小組件開始。通過緩慢地將它們組合並齧合成更大的組件，我們可以獲得更多的功能和能力。直到我們達到我們設想的理想系統。

（正確）使用類是將系統分解成最好的類。儘可能。這樣你就可以在某個時間和某個特定的抽象層次上看到某些東西，而不會被目標和邏輯所淹沒，而這些目的和邏輯並不涉及你目前關心的領域。每當你設計一個系統，想想你自己的解剖學;認爲如何你會設計人體。每當你設計一個系統，想想開辦一家新公司;什麼是主要部門，您需要經營業務的部門。運行這些部門所需的員工類型是誰？他們需要使用各種設備並與之互動以完成工作。你如何將業務運作分解爲最好的，讓自己更好地理解它？

當你理解一些物體是由較小的物體構成的基本原理時，你將會創造出高度可重複使用的細胞或分子。

Answer 8

在我可以同時處理一個複雜項目的一個小方面方面，類對我來說最有幫助。能夠從大型項目中分離代碼的一個方面是非常有用的，所以你不會感到不知所措。最後，這些課程之間的凝聚力可以​​讓您快速瞭解程序的工作方式，而無需處理內部問題。

就可維護性而言，在我看來，查看UML類圖並計算出查看函數列表的一切方式要容易得多。

Answer 9

我認爲通過說班，你應該指對象。類只不過是你可以放入對象的地方。由於某種原因，OOP範例非常成功。一旦你有這個'啊！'當你認爲自己終於理解了面向對象的概念時，就可以以更有組織的方式開始編程。我已經在Visual Basic 3中編程了很長時間，所以我在函數式編程方面有很多經驗，然後來到VB5並發現對象是一種巨大的解脫，因爲我可以將真實世界的實體與我的代碼關聯起來，並且它幫助了很多。

這就是它的重點，在代碼中重現真實世界的實體。它使閱讀和工作更容易，因爲你可以拿起東西，做東西或做東西。

Answer 10

通過使其不必要地複雜化（OO一路下降），可能過度設計一個簡單的問題。但是，對於任何足夠大的問題，我認爲OO範例首先不可能是造成它大的原因。以一個操作系統爲例，很難想象如果它不是以面向對象的方式編寫的話，它很容易維護（代碼方面）。

Answer 11

如果在大型應用程序中有一堆「裸」功能，則很難對這些功能進行更改。

• 很難看到誰在使用功能（「如果我改變了，誰造成影響？」）
• 難以更改的功能而不會破壞別人的代碼。

如果您將函數封裝在類中，則有助於隔離代碼的範圍。這不是一個神奇的子彈，但它有幫助。