爲什麼子類化是不可取的？

Question

爲什麼UIApplication類需要委託代表它完成「事情」？爲什麼不能直接做「事情」而不需要中間對象，如委託？這個原則的目的是什麼？

以同樣的方式我問自己：爲什麼不能直接訪問鍵盤來解除它？爲什麼需要將視圖控制器作爲代表發信號以便辭職第一響應者？

Answer 1

委託是一種核心設計模式。它允許在你的程序的各個部分之間分離責任。這個想法是，你的程序的一部分，例如，繪製到屏幕上可能不應該與你的數據庫交談。這有幾個原因：

1. 性能：如果繪製到屏幕的相同對象訪問您的數據存儲，則會遇到性能問題。期。句號。

2. 代碼維護：更容易概念化正確模塊化的代碼。 （對於我來說，反正）

3. 靈活性：如果您在代碼中繼承，這是偉大的 - 直到你開始運行到有各種各樣的意外的行爲，單片類。您將達到您必須重載行爲才能解決問題的地步，並且您的屬性名稱空間可能會被污染。嘗試類別，授權和塊爲altrnatives。正如所羅門王在傳道書中所說，他解釋說：在太陽下有一切時間和地點。

爲了更易於編寫，讀取，迭代和維護您的程序，強烈建議您遵循某些實踐。歡迎您爲許多類繼承子類，並且蘋果公司不會拒絕您的糟糕代碼的應用程序，前提是它的運行方式與廣告相同。也就是說，如果你不遵守具體的嘗試和真實的做法，你正在挖掘自己的墳墓。子傳球本質上並不壞，但類別，協議和街區非常迷人，無論如何我更喜歡它們。

Answer 2

代表是非常有用的，但他們也有自己的位置和時間。也可以在不使用代表的情況下進行討論。不過，在某些情況下，代表很重要。例如，當您使用uiTextview委託時，控件類知道文本何時更改以便它可以處理它很重要。而且，因爲不同的類可能需要以不同的方式處理此事件（限制字符，大寫字母等），因此使用委託最容易。

您可能會說：是的，但爲什麼不只是製造一個具有所需行爲的子類呢？那麼，這是可能的，但有幾個原因你不應該這樣做。首先，您可以重寫在委託被調用之前發生的行爲。接下來，它可能是危險的，因爲你可能會無意中重載一個必需的函數。第三，它有更多的工作和更多的代碼，所以調試起來會更困難。想象一下你有一個有100個文本框的表單，它們都有不同的行爲。你不想創建100個子類......它更容易做一個切換案例和適當的委託。

Answer 3

爲什麼子類化是不可取的？

子類化不是不可取的。只是它並不總是正確的解決方案，通常使用組合而不是繼承。很多人已經在Stack Overflow上寫過很多關於這個問題的文章，你的標題將這個問題置於重複關閉的危險之中。而不是試圖重複，我就指出覆蓋這個話題比較流行的一個問題：Prefer composition over inheritance?

爲什麼UiApplication類，需要委託有「東西」做代表其 ？爲什麼不能在沒有 需要中間對象（如委託）的情況下直接執行「事情」？該原則的目的是什麼？

它提供了一個非常鬆散的耦合，它允許Apple在不破壞現有代碼的情況下更改或替換應用程序對象。