您需要多長時間才能在日常編程中創建真正的班級層次？

Question

我使用大量數據庫創建業務應用程序。大部分編程工作只是將組件連接到數據庫並修改組件以適應一般的接口行爲。我主要使用Delphi和其豐富的VCL庫，並且通常購買所需的組件。我將大部分業務邏輯保存在數據庫中。我很少有機會從底層開始構建一個好的類層次結構，因爲實際上沒有必要。任何人都有這種經歷？

Answer 1

這個問題的答案不完全是語言不可知的;

有些像Java這樣的語言具有相當有限的可用語言特性，這意味着子類化經常被使用，因爲它是一種方便的方法用於重用和技術繼承。

由於技術原因，C＃的閉包和lambdas使得繼承關係更不相關。所以通常繼承是用於語義的原因（如貓延伸動物）。

最後一個C＃項目我的工作，我們或多或少的所有的類層次的幾個星期之內。之後，它或多或少地結束了。

在我目前的java項目中，我們總是創建新的類層次結構。

其他語言將具有其他功能，同樣會影響該組合物（混入浮現在腦海中）

Answer 2

我穿上我的建築/類設計帽可能每月一次或兩次。這可能是我擁有的最好的帽子，穿起來最有趣。

取決於您的項目在生命週期中的哪個階段。

Answer 3

當你熟悉的問題領域已經有了一個通用的代碼庫，你通常不需要創建一個新的類層次結構。當你偶然發現問題時你還沒有現成的解決方案，那麼你就開始建立自己的解決方案。

它也非常依賴於你開發的應用程序的類型。如果你的域名已經有很好的公約和圖書館可供使用，那麼可能沒有必要重新發明輪子（除了個人/學術興趣）。有些地區可用的資源本質上較少，在這些地區，大多數時候你會發現自己從頭開始構建一切。

Answer 4

它確實取決於您正在進行的項目的類型/階段。我每天都這樣做，因爲我正在爲新的數據庫開發數據庫內部部件，並創建相關的庫/框架。如果我在一個使用其他人的圖書館的成熟框架內工作，我想可以少得多。

Answer 5

大多數應用程序，特別是業務應用程序，至少包含某種業務邏輯。我認爲業務不應該在數據庫中，而應該放在應用程序中。您可以將參照完整性置於數據庫中，因爲我認爲這是一個不錯的選擇，但業務邏輯應該只在應用程序中。

通過類層次結構，我想你的意思是你總是必須在對象模型中產生一些繼承，那麼答案是否定的。但是你可能經常會發現一些通用代碼，並將其分解並創建一個基類來包含通用代碼。

如果您同意我關於業務邏輯不應該在數據庫中，但應該在應用程序中的觀點，那麼我建議您查看MVC設計模式來指導您的設計。你會發現你的設計包含類或對象。您的VCL將代表您的視圖，並且您可以讓您的模型類直接映射到數據庫表，即模型中類中的每個成員都對應於數據庫表中的字段（同樣，這是常規，但會有異常，這種簡單性不適用）。然後，您需要一個圖層來處理Model類的CRUD（創建，讀取，更新，刪除）到數據庫表。您最終將得到一個更易於維護和增強的「分層」應用程序。

Answer 6

對於我來說，偶爾的一個問題是子類更清晰或更容易，但不是經常。

這也因爲它的重構改變了一個給定的設計頗有幾分。

我最大的問題是，程序設計課程和文本給通過基類這麼多的重量，以繼承，層次結構和多態性（對接口或動態類型）。這有助於創建大量的程序員，將所有東西和他們的母親劃分爲子類。

Answer 7

我發現的類層次最有利的時機是當對象之間的關係其實並不符合真正的「是一個」在域關係。

但是，如果我能避免大的層次，我會因爲事實上，他們往往更有點棘手映射到關係數據庫，可以真正複雜的數據庫設計。既然你說你的大部分應用程序都會大量使用數據庫，那麼這是需要考慮的。

Answer 8

這取決於您的意思是層次結構 - 繼承還是分層？

當面向對象語言第一次出現時，繼承被過度使用。複雜的層次結構很常見。現在，接口（如Java和C＃中）提供了一種更簡單的方式來獲得多態的好處，而沒有繼承的複雜性。我很少使用繼承。

但是，創建大型應用程序時，分層是至關重要的。分層可以防止一般的低級類（如列表）直接引用特定的高級類（如Web瀏覽器窗口）。據我所知，沒有一種形式化的分層方法，但有一般的指導方針（模型 - 視圖 - 控制器（MVC），從業務邏輯中分離出GUI邏輯，從演示中分離數據等）。

Answer 9

我這樣做對我們公司的產品架構，所以我寫了很多稍後會在其他球隊球員被使用的代碼。所以我最終寫了很多抽象類，接口，層次結構等等。大多數情況下，它只是一種「抽象/虛擬類中的默認行爲，其他程序員可能會忽略」的模式。

非常具有挑戰性，我必須說。