Избежание безумия наследования

Question

Итак, у меня есть API, который мне нужно реализовать в существующей среде. Этот API-интерфейс управляет взаимодействием с внешним сервером. Мне было поручено придумать способ создания легко повторяемого «шаблона», чтобы, если люди работают над новыми проектами в данной среде, у них было простое решение для интеграции API.

Моя первая идея состояла в том, чтобы создать класс для вашего "основного" класса фреймворка, который бы предоставил все виртуальные функции, необходимые для взаимодействия с API. Тем не менее, мой босс наложил вето на это, поскольку существующая структура является «тяжелой наследственностью», и он хочет избежать добавления безумия. Я, очевидно, не могу инкапсулировать свой API, потому что это то, что должен делать сам API, и это может скрыть функциональность.

Если не попросить фьючерсных разработчиков скопировать и вставить мой пример, что мне делать?

Answer 1

Если ваш босс враждебен к наследованию, попробуйте агрегацию. ( Имеет отношения -a , а не отношения is-a наследования.) Предполагая, что вы взаимодействуете с соответствующим API через объект, возможно, вы можете просто сохранить этот объект в свойстве Framework 'основной' класс, так что вы будете взаимодействовать с ним как main->whateverapi->doWhatever(). Если API не является объектно-реализованным или вам нужно загрузить в него множество функций, специфичных для вашей среды, это указывает на создание собственного класса, который выполняет эту роль и относится к стороннему API, как это необходимо. Да, это в основном означает, что вы создаете API для API. Агрегация позволяет избежать проблемы функциональности маскирования; даже если вам действительно нужен промежуточный уровень, вы можете выставить исходный API как main->yourobject->originalapi и не беспокоиться о наследовании, портящем наследство.

Answer 2

Как и ответ из хаоса выше, я собирался предложить агрегацию как альтернативу наследования. Вы можете обернуть API и сделать его настраиваемым либо через свойства, либо с помощью внедрения зависимостей.

Также по теме см. Мой ответ на « Чем отличаются шаблоны прокси, декоратора, адаптера и моста?

Answer 3

Похоже, что у вашего босса есть проблема - это часть платформы. Между фреймворком и API существует важное различие: для того, чтобы кодировать фреймворк, вы должны хорошо понимать его и то, как он вписывается в вашу общую разработку, гораздо более цельный взгляд, добавление к фреймворкам никогда не следует воспринимать легкомысленно.

API, с другой стороны, являются просто интерфейсом к вашему приложению / Framework и, как правило, просто библиотекой вызовов утилит, я не вижу, чтобы у него были проблемы с наследованием или агрегацией в библиотеке, мне кажется, что проблема заключалась бы в создании дополнительной сложности в самой структуре, то есть требование к разработчикам расширить основной класс инфраструктуры намного более обременительно, чем создание отдельной библиотеки API, в которую люди могут просто позвонить (если они захотят), я бы поспорил что вашему боссу было бы все равно (на самом деле, вероятно, поддерживается), если бы сама библиотека содержала наследование.