作者：Erica Sadun，原文鏈接，原文日期：2015-12-18
譯者：JackAlan锌唾；校對：靛青K；定稿：shanks
你上一次在 Swift 中繼承一個類是什么時候动知？而且這個類是你創(chuàng)建的但不是 Cocoa 體系中的一部分。在 protocol 擴展和一般的 extension 擴展存在的情況下员辩，你多久繼承一次非 Cocoa 類型的 class 盒粮？
如果你的答案在 0% 和 5% 之間，那你是相當具有代表性的屈暗。在 Swift 的類型體系中，引用類型不再使用繼承來緊密耦合了脂男。
進一步來說养叛，問你多久創(chuàng)建一次類和子類的目的是：他們將來會被繼承，通過一個特定模塊之外的 API 客戶端宰翅。(假設(shè)弃甥，當然，你不是 Apple汁讼，并且你沒有在寫 view 和 controller)淆攻。
當繼承成為例外而不是規(guī)則，是時候考慮默認創(chuàng)建 final 類嘿架？或者將模塊封裝為 internal-by-default 更好瓶珊？這樣公開類在原模塊外就不能被繼承。
辯論目前如火如荼的展開在 Swift 進化列表中耸彪，關(guān)于這如何進行伞芹，以及是否應(yīng)該這么做，是否類應(yīng)該被設(shè)計為強制調(diào)用父類以重寫方法(需要上層調(diào)用)蝉娜。
John McCall 寫道：
我們目前的意圖是唱较，公開的繼承和重寫將被鎖定為默認，但是內(nèi)部的繼承和重寫不會召川。我認為這達到了平衡南缓，此外，這與一般語言的代碼演進是一致的荧呐，通過以下幾種方式將促進 “無副作用” 迅速發(fā)展：
(1) 避免手工管理的障礙汉形，當你正在 hack 一個模塊最初的實現(xiàn)代碼纸镊，但是
(2) 不會讓最初的實現(xiàn)代碼在內(nèi)部隱源，并且二進制兼容允許模塊之外的代碼获雕，以及
(3) 提供良好的語言工具薄腻，來逐漸的把那些最初的原型接口構(gòu)建為更強的內(nèi)部抽象。
所有默認行為的硬限制都維系在模塊邊界上届案，因為我們假定庵楷，當你之前犯了一個錯誤的決定，這能直接的在模塊內(nèi)部修復(fù)任何問題楣颠。
所以尽纽，okay，默認一個類是可繼承的童漩，并且不是真的這樣設(shè)計的弄贿，現(xiàn)在模塊中有一些子類，這導(dǎo)致了一些問題矫膨。只要沒人改變?nèi)笔∏闆r (他們本可以無所顧忌的在任何情況下做差凹，但如果只需要一個外部的子類，那就不太可能去做)侧馅，所有這些子類仍是模塊內(nèi)的危尿，你仍然有自由的控制權(quán)，以糾正最初的錯誤設(shè)計馁痴。
Joe Groff 的想法：
強大的子類化能力要求有意識的設(shè)計谊娇，就像 API 設(shè)計的其他所有方面一樣。
Jordan Rose:
關(guān)于此有趣的事情是罗晕，遺漏的錯誤：沒有考慮是否一個類應(yīng)該是 final 济欢，這比另一種選擇更糟糕。這里忽略一下優(yōu)化小渊，一個開始是 final 的類法褥，之后就無法更改；這無法改變這個類目前是如何使用的酬屉，對于許多庫發(fā)展問題挖胃，這是最好的答案: 缺省情況應(yīng)該是安全的，類的設(shè)計者可以選擇以后再改進梆惯。
本文由 SwiftGG 翻譯組翻譯酱鸭，已經(jīng)獲得作者翻譯授權(quán)，最新文章請訪問 http://swift.gg垛吗。
