Каким классом правильно связать несколько классов?

Question

[Иван Антонов]

Есть несколько классов.

class Order - заказы
class Information - информация о заказе
class Field - тип и описание конкретной информации о заказе
Order::data - массив объектов класса Information
Information::field_id - объект класса Field (определяет тип и описание класса Information)

Хочу сделать классы менее зависимыми друг от друга. Скажите как правильно связать объекты? Отдельным классом? Или для связи объектов есть специальный паттерн как в JS Медиатор.
Наставьте меня на путь истинный!

Answer 1

[Ivanq]

Дополнительного паттерна нет, используй дополнительный класс

Comments

[Иван Антонов]

Я думал что Factory

[Сергей Протько]

Иван Антонов: factory это пораждающий шаблон, он тут к чему? У вас проблема с изменением данных. Лучше расскажите почему у вас вообще возникла необходимость динамически для заказа указывать дополнительную информацию?

[Иван Антонов]

Сергей Протько: самописная cms

[Сергей Протько]

Иван Антонов: не загоняйтесь вы по шаблонам проектирования. Лучше покройте все юнит тестами, они более наглядно будут говорить что у вас там связанность слишком большая или еще чего. Для всего что вы делаете должна быть причина, изменения которые вы вносите в код должны приносить какую-то ценность. Ну и да, CMS-ка как бы тоже, но я надеюсь что вы все это в плане обучения только пилите.

Вообще я все же повторюсь - может не надо делать ее настолько уж гибкой и универсатльной? Вместо массива непонятных атрибутов можно использовать 3-4 разных value object-ов реализующих один интерфейс. Это будет покрывать большую часть юз кейсов, ну и сделать это красиво намного проще. А уже на уровне DAO пихать это все в EAV как вы видимо и планировали.

[Иван Антонов]

Сергей Протько:

Вместо массива непонятных атрибутов можно использовать 3-4 разных value object-ов реализующих один интерфейс.

поясните пожалуйста. что здесь является "массивом непонятных атрибутов". и что это за value object? Я описал 3 сущности для удобной работы с материалом полученный из БД. Здесь мой код Но не знаю где запросы к БД хранить, если в сущностях, запросы будут включать в себя данные и других сущностей, помоему это не хорошо.

[Иван Антонов]

Сергей Протько: В этом методе я использую эти сущности. Наполняю их данными и сохраняю. Для дальнейшего вывода.

[Сергей Протько]

Иван Антонов: круто, вы изобрели шаблон "репозиторий". На самом деле я слегка даже удивлен, обычно изобретают всякие богомерзские active record. Читаем про persistence ignorance тогда. И может быть даже стоит взять Doctrine 2.5 в качестве ORM.

Запросы к БД должны быть вынесены из сущностей, им должно быть плевать как их хранят и где. У вас скажем в тестах они хранятся тупо в массивчике, то есть в in memory репозитории.

Что до массива непонятных атрибутов - я про поле data у заказа. Оно совершенно нелогично и смотрится весьма странным. Как минимум мне кажется странным давать пользователю CMS возможность накликать атрибуты для заказа. Это конечно круто, но вызовет больше проблем чем пользы. Коль уж делаете что-то интересное, то задумайтесь о том как упростить поддержку системы программисту, таких CMS увы не так много.

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

[Сергей Протько]

Иван Антонов: ну и да, Value Object-ы это... собственно объекты-значения. Это какой-то объект с набором свойств, который являет собой одно значение. В нашем случае весь набор дополнительных атрибутов заказа - это одно значение, грубо говоря "набор дополнительных атрибутов". И тип у него может быть например AdditiionalInformation. Это может быть объект-коллекция ваших классов Information, или просто статический объект... или внутри может лежать массив. Тут как говорится вы сами себе хозяин. И тут как раз таки может пригодиться фабрика - что бы генерить это дело и запихивать в сущность при загрузке из базы данных.

Вариантов масса, но основная идея - спрячьте этот массив в каком-то отдельном классе, который будет уметь работать с кастомными атрибутами. Сущности "заказ" можно просто сказать "прими вот этот набор доп. атрибутов", и ему будет без разницы как оно там что реализовано.

[Иван Антонов]

Сергей Протько:

круто, вы изобрели шаблон "репозиторий". И может быть даже стоит взять Doctrine 2.5 в качестве ORM.

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

У вас скажем в тестах они хранятся тупо в массивчике

Это аналог возвращаемых данных из БД.

Что до массива непонятных атрибутов - я про поле data у заказа.

Я долго подбирал название, в голову так ничего и не пришло поэтому написал просто data. ) это массив-коллекция информации.

$this->data = array(
  new Information(),
  new Information(),
);

У одного заказа может быть много информации такие как имя, телефон, майл. Для каждого свой класс информации.

Как минимум мне кажется странным давать пользователю CMS возможность накликать атрибуты для заказа

Эта функция для админов. Дабы расширять свои формы на сайте.

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

Мысль сейчас только о заказах. так как CMS для лендинга.

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

[Сергей Протько]

Иван Антонов: нет, в фабрике только логика по созданию объекта, инкапсулирующего все эти атрибуты и т.д. Ее задача - достать из базы все атрибуты и собрать объект-коллекцию. Не более. В целом не загоняйтесь по названиям паттернов, еще успеете. Вы так заранее пытаетесь подогнать свою архитектуру к какому-то паттерну, при том что соблюдая правила SOLID и GRASP вы всеравно придете к чему-то схожему, но с более адекватными названиями.

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

Я не изобретал его, я сделал что-то подобное

так может и назовите его OrderRepository? Хотя это мелочи. Но в целом я серьезно приятно удивлен что вы пошли именно этой дорогой.

Это аналог возвращаемых данных из БД.

Соль репозитория в том, что именно он хранит данные, а не база данных или что бы то нибыло еще. Он может использовать базу данных как часть своей реализации, но с точки зрения пользовательского кода - без разницы где это все хранится. Единственное что - все это красиво только вместе с unit-of-work и т.д. Иначе возникают сложности.

[Иван Антонов]

так может и назовите его OrderRepository? Хотя это мелочи.

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

[Иван Антонов]

Сергей Протько: Наставника не хватает наверно :-)

[Сергей Протько]

Иван Антонов: ну вы можете начать читать книжки, это тоже дело полезное. А если вам нравится этим заниматься - то почему бы и да?)

[Иван Антонов]

Сергей Протько: не знаю хороших книг по грамотному программированию на php с описанием архитектуры и всего что влияет на качество кода. У нас в городе в книжных нет таких, есть только азы программирования на php. В интернет-магазинах книжку не полистаешь и не оценишь - полезна ли она тебе будет.

[Сергей Протько]

Иван Антонов: читайте по Java, их больше, они круче, и знания проэцируются на PHP без проблем. Почитайте Эванса, Фаулера, Боба Мартина...

[Иван Антонов]

Сергей Протько: ок. Спасибо.

[Иван Антонов]

становится грустно, что нет ни одной CMS ориентированной исключительно на разработчика

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

Пока что для меня важно только валидация данных. По-моему ничего лишнего. Только думаю связанность классов Order и Category лишняя, может в атрибуте category хранить только id категории.
Если я в статическом свойстве Category буду хранить все категории, то не трудно будет по id найти нужную мне категорию.

[Сергей Протько]

Иван Антонов: а откуда взялась категория у заказа? Она же должна быть у заказанного товара (OrderedProduct или что-то в этом духе).

[Иван Антонов]

Сергей Протько: тут нет товаров. Лендинг предлагает одну услугу. Категории предназначены для сортировки заказов. Категории могут быть: Новые, Принятые, Неизвестные, Удаленные. Это для удобной обработки заказов админами.

[Сергей Протько]

Иван Антонов: это не категории а статус, нет? И обычно это делают просто полем в объекте.

[Сергей Протько]

Иван Антонов: если же вы хотите что бы у админа была возможность самому выставить статусы - то да, тогда норм. Но опять же лучше назвать это Status.

[Иван Антонов]

Сергей Протько: Ок, так и сделаю.

[Сергей Протько]

Иван Антонов: отдельным полем если статусы ограничены. Если статусы должны работать по типу категорий (например админ может ввести новый статус для заказа, что бы адаптировать все под свой флоу работы) - то тогда схема приведенная вами вполне себе валидна.

[Иван Антонов]

Сергей Протько: Ага, полезно. Я планирую статусы хранить в БД. Только думаю что нужно статусы Новый и Удаленный как-то зарезервировать и скорее всего не на уровне БД, а на уровне класса. Потому что у них иные задачи, особенно у статуса Удаленные.

[Сергей Протько]

Иван Антонов: статус "удален" чаще называют "мягкое удаление" или soft delete. Ну так... на всякий.

[Иван Антонов]

Сергей Протько: понятно, вот что получилось

[Сергей Протько]

Иван Антонов: это у вас Order отнаследован от Fields? А зачем? Пусть это будет просто вложенным объектом.

[Иван Антонов]

Сергей Протько: Fields несет в себе дополнительные поля будущей таблицы orders. В этом особого смысла нет, все поля можно перенести в Order. Я вынес их в отдельный класс для удобства и разделения служебной информации и информации введенной пользователями. а дополнительная вложенность усложнит работу с данными.

[Сергей Протько]

Иван Антонов: почитайте про объекты значения. В целом усложнять специально систему не стоит. Совершенный код всеравно не достижим, так что не стоит даже загоняться. Главное понимать что такое технический долг и понимать когда и сколько можно "отдолжить".

[Иван Антонов]

Сергей Протько: прочитал тут. То есть мне для каждого пользовательского поля создавать объект? или создать общий объект для всех полей? для меня это ново, объясните, как вы это видите?

[Сергей Протько]

Иван Антонов: для всех полей объект. То есть смысл в том, что бы объеденить поля, общие по назначению в объект. Скажем у нас есть дополнительная информация, и создаем мы объект AdditionalInformation или что-то в этом духе. Скажем мне нравится когда у пользователя его публичный профиль обернут в объект PublicProfile или UserProfile. Так обновление профиля у меня будет реализовано методом setProfile, а вся логика по валидации и прочее выносятся из сущности.

[Иван Антонов]

Сергей Протько: Мне кажется неудобным работать с вложенным объектом. Раньше я мог просто пройти один объект собрать все данные и провести сохранения, а теперь мне еще нужно задуматься о вложенном объекте.

[Иван Антонов]

Сергей Протько: и наполнять данными сущность гораздо проще без вложенных объектов, например просто передав ему массив данных полученный от бд.

[Сергей Протько]

Иван Антонов: я это прекрасно понимаю, потому и рекомендую для работы с базой и организации сущностей не пилить свой велосипед а воспользоваться доктриной, которая все это умеет.

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

[Иван Антонов]

Сергей Протько:

Просто наследование надо применять осторожнее.

Почему?

[Сергей Протько]

Иван Антонов: в 90% ситуаций которые я видел наследование могло быть заменено декорированием и композицией. Так же не стоит забывать про LSP

[Иван Антонов]

Сергей Протько: про декорирование впервые слышу. По поводу LSP я рассчитывал на составление мной уникальных полей и методов. Сейчас думаю вернуть всё в один класс.

[Иван Антонов]

Сергей Протько: Перенести все методы и поля из Fields в Order

[Сергей Протько]

Иван Антонов: да ладно, шаблон "декоратор".

[Иван Антонов]

Сергей Протько: теперь знаю что это :)