Кто-либо использующий Qi4J
Я читал статью InfoQ о Составном Ориентированном Программировании раньше:
http://www.infoq.com/articles/Composite-Programming-Qi4j
Я интересовался обнаружением, использует ли кто-либо в настоящее время (или использовал), платформа Qi4j вообще?
Как делает это сравнивает с использованием традиционной платформы внедрения зависимости те, которые Кидаются за проводным соединением классов вместе. График полученного объекта (на основе mixins, а не классов) легче иметь дело с с точки зрения обслуживания?
3 ответа
Ну, я сам уже около года использую Qi4j в проекте. Как только вы привыкнете к мощи миксинов в своей модели предметной области, вам будет интересно, как вы раньше обходились без них. Фактически, я считаю, что метод создания моделей предметной области с помощью POJO должен быть устаревшим. Он создает системно неподдерживаемый код. Поскольку смешанная / составная модель является важной особенностью Qi4j, а не DI, на платформе Java действительно нет никакого сравнения.
Что касается опасений Божо: когда дело доходит до объявления миксинов, есть два отдельных случая. В сущностях, то есть в модели предметной области, интерфейс, как правило, имеет только одну реализацию, и вы действительно хотели бы активно избегать использования нескольких реализаций по причинам обслуживания и читаемости. Поэтому я заявляю о реализации прямо в интерфейсе. Но это только значение по умолчанию, которое при желании может быть отменено композицией. Я до сих пор никогда не видел в этом необходимости.
Другой случай - это услуги, и это совсем другое дело. Во многих случаях будет только одна реализация, поэтому объявление реализации в интерфейсе снова вполне нормально. Но гораздо больше случаев со службами, которые вам нужны разные реализации, и поэтому для этих случаев вместо этого вы просто объявляете миксин в конкретном объявлении составного типа. Так что оба стиля возможны и рекомендуются по разным причинам.
Что касается заклинания, то возможность сотворить предмет - это бонус, а не проблема.Если у вас нет преобразования из одной роли в другую, вам придется проявить изобретательность, чтобы обойти это, что, вероятно, не упростит ваш код.
Прочитав первую часть связанной статьи, я не стал вроде двух вещей:
- реализации определены в интерфейсе (с использованием
@Mixins) - что, если они должны быть имитированы, или реализации должны быть изменены? - требует преобразования
Отсутствие опыта работы с Qi4J , Не могу сказать, как это получается на практике, но это не очень хорошо.
Надеюсь, не слишком поздно спохватился:
Но вот как я это вижу.
Прежде всего мне нравятся идеи (Composites, Mixins, Assemblies), лежащие в основе Qi4j, но меня сдерживает сложность их использования.
Эти концепции должны быть частью более широкого зонтика, например, языка (такого как Java), а не фреймворка, и должны быть проще в использовании.
2 года назад я столкнулся с проблемой, которая заставила меня пожалеть, что у меня тогда не было чего-то подобного.
Мне нужно было 3 различных поведения, которые можно было бы повторно использовать в наборе бобов. Некоторые бобы использовали все из них, другие - любую комбинацию из двух. Я не хотел объединять их все в класс, потому что это не имело смысла. С другой стороны, меня ограничивал тот факт, что я не мог использовать множественное наследование. Очевидное решение: использовать интерфейс; что означает реализовать вещь столько-то раз. Я помню, как жаловался коллеге на то, что надеюсь, что у меня есть способ предоставить реализацию по умолчанию для интерфейса. Для меня это простая концепция ОО, которая позволяет повторно использовать поведение более чистым способом. А если вам нужно что-то отличное от реализации по умолчанию, то реализуйте это. Это имело бы больше смысла и не нарушало бы никаких естественных законов, которые я вижу.
Поэтому, отвечая на ваш вопрос, я думаю, что концепции Qi4j позволяют вам мыслить OO более чисто, в то время как Spring более структурна и даже не сопоставима концептуально. Вы можете думать об инъекции зависимостей и не думать о Spring, а также думать о Qi4j и не думать об инъекции деплоя.