Ищете отзывы об использовании шаблона адаптера - PullRequest
1 голос
/ 28 июня 2009

В рабочем проекте у нас есть определенный класс типов значений в нашей модели предметной области, который включает в себя очень большое количество атрибутов ...

public class BigValueType {
    private Foo foo;
    private Bar bar;
    private Baz baz;

    //...
}

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

public class SpecializationA {
    private Foo foo;
    private Baz baz;
    //...
}

public class SpecializationB {
    private Bar bar;
    private Baz baz;
    //...
}

private class SpecializationC {
    private Foo foo;
    private Bar bar;
    //...
}

Однако эта модель предметной области должна быть довольно общей и не специфичной для данного проекта. В будущих проектах к нему будут добавлены специфичные для проекта расширения, но модель общего домена будет отделена от этих расширений. Если мы сейчас просто определим группу классов, вполне вероятно, что другие проекты, использующие модель предметной области, просто позже должны будут написать свои собственные немного другие. (Мы не можем легко предсказать, какие виды этих данных будут полезны.)

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

public class AdapterA {
    private BigValueType wrapped;
    //...

    public ViewA(BigValueType wrapped) {
        //...
    }

    public Foo getFoo() {
        return wrapped.getFoo();
    }

    //...
}

Это имеет для меня больше смысла, чем обычное наследование, потому что в нашем классе / интерфейсе верхнего уровня почти ничего не будет.

Есть ли какие-либо отзывы об этом подходе?

Ответы [ 3 ]

1 голос
/ 28 июня 2009

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

Сказав это, это довольно распространенный дизайн в мире SOA. У вас есть большой сервис, который принимает сложное сообщение с довольно большим количеством атрибутов в качестве запроса. Эта услуга затем «адаптируется» для обслуживания клиентов с различными потребностями. Итак, ваш дизайн должен работать хорошо. Конечно, это предполагает, что вы уже знаете все возможные «представления» или вам придется писать новые адаптеры для новых клиентов.

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

Альтернативным подходом для рассмотрения также может быть способ REST сделать это - выставить данные (Foo, Baz и т. Д.), Пусть и из основного класса, и позволить клиентам самостоятельно обрабатывать данные с помощью основного класса по существу, предоставляя функции CRUD для этих данных. Тогда ваш класс будет вести себя как структура без реальной бизнес-логики.

Любой из этих трех подходов должен быть в порядке, ИМХО.

0 голосов
/ 28 июня 2009

Я обнаружил, что цель совместного использования кода несколькими проектами сложнее, чем кажется. Как минимум, трудно понять правильно ! Это именно по тем причинам, которые вы обсуждаете, не зная точно, какие функции вам могут понадобиться в каком-то новом проекте. Проблема в том, что проблема с адаптером не решит эту проблему за вас (если базовые объекты не поддерживают требуемый набор функций).

Я бы посоветовал вам использовать interfaces для ваших отдельных проектов, но кодировать реализации отдельно. Если вы обнаружите, что пишете в точности один и тот же код 3 раза, вытащите его в общую библиотеку. Старайтесь, чтобы ваша библиотека была максимально легкой.

Управление множественными зависимостями может оказаться дорогостоящим позже, когда вы обнаружите, что вам нужно добавить функции - возможно, конфликтующие , - и у вас есть сложности, влияющие на множество приложений.

0 голосов
/ 28 июня 2009

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

...