Как избежать безумия наследования
Итак, у меня есть API, который мне нужно внедрить в существующую структуру. Этот API управляет взаимодействием с внешним сервером. Мне было поручено придумать способ создания легко повторяемого «шаблона», чтобы, если люди работают над новыми проектами в данной структуре, у них было простое решение для интеграции API.
Моя первая идея состояла в том, чтобы создать класс для вашего «основного» класса фреймворка, чтобы расширить его, предоставить все виртуальные функции, необходимые для взаимодействия с API. Однако мой босс наложил вето на это, так как существующая структура является «тяжелой по наследству», и он не хочет добавлять безумие. Я, очевидно, не могу инкапсулировать свой API, потому что это то, что должен делать сам API, и это может скрыть функциональность.
Если не просить разработчиков фьючерсов скопировать и вставить мой пример, что мне делать?
Ответы 3
Если ваш босс враждебно настроен по отношению к наследованию, попробуйте агрегирование. (Отношения Имеет, а не отношения наследования это.) Предполагая, что вы взаимодействуете с рассматриваемым API через объект, возможно, вы можете просто сохранить этот объект в свойстве своего «основного» класса фреймворка, чтобы взаимодействовать с ним как с main->whateverapi->doWhatever(). Если API не является объектно-реализованным или вам нужно загрузить в него множество функций, специфичных для вашей среды, это указывает на создание вашего собственного класса, который входит в эту роль и относится к стороннему API, как бы это ни было необходимо. Да, это в основном означает, что вы создаете API для API. Однако агрегирование позволяет избежать проблемы с функциональностью маскирования; даже если вам нужно создать промежуточный уровень, вы можете предоставить исходный API как main->yourobject->originalapi и не беспокоиться о том, что наследование все испортит.
Да, взаимодействие с API осуществляется через объект. Я думаю, что лучший способ сделать это - изменить основной класс, чтобы иметь возможный доступ к API (по вашему предложению), а затем включить или выключить его с помощью файла свойств. По характеру API объект просто не будет создаваться.
Для меня это звучит так, как будто у вашего босса проблемы с рамками. Существует важное различие между Framework и API: чтобы кодировать структуру, вы должны хорошо понимать ее и то, как она вписывается в вашу общую разработку, а тем более целостное представление, добавление к фреймворкам никогда не следует воспринимать легкомысленно.
С другой стороны, API - это просто интерфейс для вашего приложения / фреймворка и обычно просто библиотека вызовов служебных программ, я не вижу, чтобы у него была проблема с наследованием или агрегацией в библиотеке, мне кажется, что проблема будет в создание дополнительной сложности в самом фреймворке, т.е. требовать от разработчиков расширения основного класса фреймворка гораздо сложнее, чем создание отдельной библиотеки API, которую люди могут просто вызвать (если они захотят). Я готов поспорить, что ваш босс было бы безразлично (на самом деле, вероятно, поддерживает), если бы сама библиотека содержала наследование.
Как и в ответе из приведенного выше хаоса, я собирался предложить агрегацию в качестве альтернативы наследованию. Вы можете обернуть API и сделать его настраиваемым либо с помощью свойств, либо с помощью внедрения зависимостей.
Также по связанной теме см. Мой ответ на «Чем отличаются шаблоны прокси, декоратора, адаптера и моста?» для уточнения других шаблонов проектирования «оболочки».
Можете ли вы опубликовать какой-нибудь псевдокод, чтобы прояснить ваш вопрос?