Objective-C中的對象層次結構

Question

我已經被介紹到具有〜50,000 LoC的Objective-C代碼庫，並且我估計25％左右是重復代碼。 不幸的是，到目前為止，在代碼庫中，面向對象的原理一直被忽略，而采用了復制和粘貼邏輯。 好極了！

我來自Java背景，許多此類重復可以通過良好的老式面向對象編程來解決。 在很多情況下，將共享邏輯提取到基類中似乎是正確的解決方案。

但是，在我開始創建一堆基類並在派生類之間共享通用邏輯之前，我認為我應該停下來看看是否有其他可用的選擇。 在觀看了Ken Kocienda從2011年開始的WWDC的“編寫易於更改的代碼”會議之后，他建議我將對象層次結構保持盡可能淺。 他沒有就他為什么有這種觀點提供任何確切的統計數據，所以我想知道我是否錯過了某些東西。

憑空想象，我不是Objective-C專家，所以我想知道在確定對象層次結構時是否有最佳實踐。 基本上，當您決定停止創建基類並開始使用合成而不是繼承作為在類之間共享代碼的方式時，我想征詢您的意見。

而且，從運行時性能的角度來看，有什么可以讓我遠離創建對象層次結構的嗎？

Answer 1

我有段時間想起從其他背景 （包括Java） 進入iOS的想法。 由於ARC，某些情況已更改。 特別是，內存管理不再是中心問題。 也就是說，您過去為簡化內存管理所做的所有事情（使用訪問器，使用訪問器，使用訪問器）在ARC中同樣有效。

@Radu是完全正確的，您應該經常使類層次結構相當簡單和淺（如您所讀）。 在Cocoa中，組合通常是比擴展子類更好的方法（在Java中也可能如此，但在ObjC中是常見的做法）。 ObjC也沒有抽象方法或類的概念，這使得某些類型的子類有點尷尬。 與其將共享邏輯提取到基類（尤其是抽象基類）中，不如將它們提取到單獨的策略對象中通常更好。

查看UITableView及其對委托和數據源的使用。 看一下像NSAttributedString這樣的東西，它是HAS-A NSString而不是IS-A。 這很常見，通常會使事情更清潔。 與所有大對象層次結構一樣，始終要記住LSP 。 當有人忘記正方形不是矩形時，我會看到很多ObjC設計都是橫行的。 同樣，所有語言都是如此，但是在設計時值得記住。

只要使用不可變（值）對象，它們都是真正的勝利。

您很快就會發現的另一件作品是，很少有諸如“最終”或“受保護”之類的“安全裝飾”（有@protected ，但實際上在實踐中並沒有那么有用，並且很少使用）。 來自Java和C ++背景的人們傾向於對各種訪問規則的編譯器強制執行感到煩惱。 ObjC沒有大多數保護措施的編譯器實施（您始終可以在運行時將所需的任何消息發送給任何對象）。 您只需要使用一致的命名約定，就可以隨意使用私有方法。 程序員紀律代替了編譯器強制。 實際上，它在大多數情況下都可以正常工作。

就是說，ObjC有很多警告，您絕對必須消除所有警告。 大多數ObjC警告實際上是錯誤。

我從對象層次結構的特定問題中走了一些步，但希望它會有用。

Answer 2

Objective-C中的深層次結構的一個主要問題是Xcode根本無法幫助您理解/管理它們。 另一個簡單的原因是，Objective-C中的幾乎所有東西都比Java中的東西復雜了兩倍，因此您需要更加努力地使事情變得簡單。

但是我發現Objective-C中的合成很尷尬（盡管我不能確切地說出原因），因此沒有“完美”的答案。

我已經觀察到，在Objective-C和Java中，小的子例程要少得多，而且人們更可能看到在大多數相同的視圖控制器等之間重復的代碼。 我認為其中很大一部分只是開發工具和創建新類的相對尷尬。

PS：我不得不重做一個包含大約55K行的應用程序，這與我們可以估計的接近。 如您所見，可能有大約25％的重復，但是還有25％左右的完全無效代碼。 （值得慶幸的是，此應用自此以來已被廢棄。）