Действительно ли это - антишаблон?
Ситуация - это: у Вас есть два класса, которые и реализовать тот же интерфейс и оба класса сотрудничают для завершения некоторого бизнес-процесса.
Например, networkUserManager и localUserManager реализация IUserManager который имеет метод getUser(). networkUserManager.getUser() помещает запрос для получения a User на очереди и возвратах ответ. localUserManager.getUser() получает запрос от очереди, находит информацию о пользователе в некоторой базе данных и затем отвечает с пользовательскими данными.
Когда я видел что-то подобное этому сделанному, я не мог не задаться вопросом, было ли это плохим дизайном. Этот плохой дизайн и если не, что такое пример, где выполнение чего-то вроде этого было бы хорошей идеей?
6 ответов
Вы, кажется, описываете декоратор . В этом случае NetworkUsermanager предоставляет дополнительные функциональные возможности, которые обеспечивают LocaluserManager . Вы не говорите, на каком языке вы используете, но этот паттерн появляется в пакете Java.io .
С другой стороны, ваше описание localusermanager.getUser () Вытягивание сообщения с очереди, кажется неверным - это обратно от того, как работает Networkusermanager . Я бы видел это как правильный декоратор, если бы Localusermanager получил доступ к базе данных, в ответ на что-то другое (возможно, NetworkUsermanagerservice ), вызывающий GetUser () .
Предположим Networkusermanager необходимо получить данные по всей сети. Таким образом, он ставит запрос на очередь запроса на сетевой сервер, который имеет эту информацию, и Localusermanager , сидя на сервере, на самом деле службы, которые требуют запрос. Когда вы пишете одномашинную версию программного обеспечения, наверное, лучше сохранить его в значительной степени то же самое, чем тратить время разработчика, переписывая эту область без причины.
Плохой запах. Ваш интерфейс определяет контракт, который выполняет реализацию классов. В случае рисунка декоратора у вас есть несколько классов, внедряющих тот же договор, так что вы можете объединить несколько классов. Неясно, что здесь что-то подобное происходит.
Вопрос вот является ли «GetUser» осмысленной абстракцией, и ли он капсулирует вашу логику, которая выглядит для меня, как многоуровневый доступ. Я бы утвердовал, что он прячет больше, чем освещает. Например, Java.io декораторы могут (в основном) быть обременной в любом порядке; Учитывая многоуровневый доступ, который вы описываете, LocalManager.GetUser (NetworkManager.GetUser ()) имеет смысл, в то время как Networkmanager.GetUSER (LocalManager.GetUser ()) не.
Я бы не пошел бы так далеко, как называя это антипаттерном, но определенно очень плохой реализацию интерфейса. («Плохой запах», как уже упоминалось в этой теме?)
Я бы даже утверждал, что эти два метода GetUSER () должны иметь разные имена, поскольку, поскольку они имеют одинаковые значения возврата, и нет аргументов, их «семантические» интерфейсы явно явно Разные:
- localusermanager.getUser () ожидает чего-то, что он уже в очереди
- Networkusermanager.GetUser () не делает.
На первом уровне, я думаю, это выглядит как базовая очередь "продукт-потребление".
Если я вас правильно понял, у вас есть очередь. Процесс A, независимо от имени, ставит вещи в очередь. Процесс B, независимо от имени, снимает вещи из очереди и обрабатывает их.
Затем вы добавляете дополнительный незначительный усложняющий фактор в процесс A, который хочет быть уведомлен о результатах обработки очереди. Ничего особенного.
Если здесь есть плохая практика, то я бы сказал, что это именование классов и использование общего интерфейса. Не похоже, что они выполняют похожие задачи. Похоже, что они оба работают над одним и тем же классом/объектом (этой очередью).
Что пахнет мне довольно плохо. Различные классы могут иметь методы с тем же именем, конечно, но если они оба реализуют тот же интерфейс, то есть предположение, что они будут делать то же самое. Здесь они делают противоположные вещи!
Возможно, это отсутствие воображения с моей стороны, но я не могу понять, почему это когда-либо будет хорошей идеей.