避免繼承瘋狂

Question

所以，我有一個API，我需要實現一個現有的框架。該API管理與外部服務器的交互。我被指責想出一種方法來創建一個易於重複的「模式」，這樣如果人們在給定的框架中開發新項目，他們就有了一個簡單的API集成解決方案。

我最初的想法是創建你的「主」類的框架來擴展一個類，將提供一切必要的與API交互的虛擬功能。然而，我的老闆否決了這一點，因爲現有的框架是「繼承性沉重」，他想避免增加瘋狂。我顯然不能封裝我的API，因爲這就是API本身應該做的事情，這樣做可能會隱藏功能。

短，要求期貨開發者複製並粘貼我的例子中，我該怎麼辦？

Answer 1

如果你的老闆敵視繼承，試試聚合。 （擁有-一個關係，而不是繼承的是，一個關係。）假設你通過一個對象有問題的API接口，也許你可以只保留該對象在你的框架「主」類的屬性，所以你'd像main->whateverapi->doWhatever()與它交互。如果API沒有實現對象，或者需要將許多特定於您的環境的功能加載到它上面，那就指向讓自己的類進入該角色並與第三方API相關，但需要它。是的，這基本上意味着你正在爲API創建一個API。儘管如此，聚合允許您避免掩蔽功能問題;即使你必須做一箇中間層，你也可以將原始的API公開爲main->yourobject->originalapi，而不必擔心繼承會讓事情變得糟糕。

Answer 2

聽起來好像是你的老闆有一個問題，什麼是與這個框架的一部分。框架和API之間存在一個重要的區別，爲了編寫框架，您必須對框架有一個很好的理解，以及它如何適合整體開發，更加全面的觀點，添加框架永遠不要掉以輕心。

另一方面，API僅僅是您的應用程序/框架的接口，通常只是一個實用程序調用庫，我無法看到他在庫中會有繼承或聚合的問題，在我看來，這個問題會在框架本身創造額外的複雜性，即要求開發人員擴展框架的主要類比創建一個人們可以調用的獨立API庫（如果他們選擇的話）更加繁重，我會願意打賭，如果圖書館本身包含遺產，你的老闆不會在乎（實際上可能支持）。

Answer 3

就像從上面亂回答，我會建議聚合來替代繼承。您可以封裝API並通過屬性或通過依賴注入來配置它。

也爲相關的主題看我的回答「How do the Proxy, Decorator, Adaptor, and Bridge Patterns differ?」對等「包裝」設計模式破敗。