Шаблон проектирования для использования различных реализаций класса / метода

Question

Иногда мы разрабатываем более одного алгоритма, чтобы получить одинаковые результаты. Например, я написал класс, который хранит мои данные в деревьях, и другой класс, который хранит примерно те же данные, скажем, в связанных списках.

Я опубликую интерфейс (абстрактный класс) под названием ThingStore и подклассирую его в TreeThingStore и ListThingStore, каждый из которых соответственно использует деревья или связанные списки.

Однако, так как я публикую абстрактный класс, мне нужно, чтобы кто-то решил, какую реализацию использовать ( EDIT : так что вызывающей стороне это не нужно), и у меня нет проблем в том, что это жестко закодировано. Мне это нужно было не раз, но я безуспешно изучал каталоги GoF и другие шаблоны проектирования. Наиболее похожая модель - «Стратегия», но она позволяет достичь разных целей.

Итак, есть ли Design Pattern для этого намерения? Если нет, то кто-то может создать его или сказать мне, почему этого не следует делать (или есть лучшие способы достижения тех же результатов)?

Answer 1

Немного странно, что вы указали бы реализацию таким образом. Почему ваш абонент заботится о том, как реализовать конкретную функцию? Все, о чем он должен заботиться, - это то, что ваше хранилище данных хранит данные правильно и на самом деле не беспокоится о базовой структуре данных, которую вы используете. Но, скажем, реализация была выражена внешне как различные функции хранилища данных (одна лучше для большого количества вставок и одна лучше для многих операций чтения, например). Затем вызывающий объект должен указать, какой конкретный класс он хочет создать. Как дизайнер класса, вам немного самонадеянно полагать, что вы знаете как-то лучше. :)

Учитывая это, вы определенно можете заключить создание объекта в Factory и позволить своему пользователю указать Factory, какие функции важны. Вы могли бы пойти еще дальше и использовать шаблон Inversion of Control , где вы позволяете вызывающей стороне создавать экземпляры и вручать вам механизм хранения, но это кажется излишним для того, что вы пытаетесь сделать.

Answer 2

Предлагаю вам проверить Шаблон моста . Намерение состоит в том, чтобы отделить абстракцию от ее реализации, так что они могут различаться независимо друг от друга.

Инфраструктура классов коллекций в Java API предоставляет несколько примеров использования шаблона моста. Оба конкретных класса ArrayList и LinkedList реализуют интерфейс List. Интерфейс List предоставляет общие абстрактные понятия, такие как возможность добавлять в список и запрашивать его размер. Детали реализации различаются между ArrayList и LinkedList, в основном в зависимости от того, когда выделяется память для элементов в списке.

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

Answer 3

Проверьте Заводской шаблон или Шаблон адаптера (в зависимости от того, что вы ищете). Адаптер больше подходит для реализации выходной реализации, где фабрика предназначена для создания из дерева подклассов или составных классов.

Фабрика, вероятно, является вашим самым близким шаблоном, поскольку она допускает конструкции, подобные:

ThingStore theThingStore = ThingStoreFactory.GetStore("tree");