Нормально ли объединять сущности по паттернам?

Question

[Xveeder]

Всем привет!

САБЖ. Например, в рамках домена объединять фабрики в один пакет, фасады в другой и т.д.
Спасибо.

Comments

[Adamos]

А учебники у вас на полке расставлены по цвету обложек?

[Xveeder]

Adamos, мысль была такова, что объединив их по домену -- будет ясно их зона ответственности, а по паттерну -- их механизм.

[Adamos]

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

[Xveeder]

Adamos, то есть, если у нас есть модуль, который выполняет некоторый бизнес-кейс, у него есть 7 сервисов. И, например, 4 связанных с сервисами фабрики, то все эти сущности нужно смешивать в одном пакете?

[Adamos]

Xveeder, смешивать ничего не требуется. Нужно объединять то, что работает вместе. Объединять же то, что работает одинаково, никому на хрен не нужно и даже вредно. Глядя на пакет снаружи, у вас просто не должно возникать мыслей о том, КАК оно работает. Только - ЧТО делает.

[Xveeder]

Adamos, я понял ваш посыл, спасибо за доходчивый ответ.

[Сергей П]

Xveeder, раскладывайте по размеру файла. Тогда будет понятно где много кода, а где чуть-чуть.

Если вы задётесь таким вопросом, то вам еще рано что-то изобретать в этом плане. Прочитайте что такое S.O.L.I.D, читайте больше чужих хороших исходников, изучайте opensource проекты. Такие вопросы возникают чаще всего от малого опыта в разработке.

[DollyPapper]

Сергей Паньков, SOLID здесь каким боком?

[Сергей П]

DollyPapper, очень даже "при чем", когда речь идёт о том, как сгруппировать фрагменты кода.
Модули и пакеты не для красоты, они тоже должны подчиняться этим принципам. А их начинают раскладывать "по цвету обложки", а не по зоне ответственности и контексту.

[DollyPapper]

Сергей Паньков, вы скорее об SRP говорите я так думаю. Не понятно как пакеты будут подчиняться LSP например.

[Сергей П]

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

Answer 1

[mayton2019]

Да можно. Но обычно объединение идет по модулям приложения. Это упрощает процесс релиза. Например если меняется что-то в модуле работы с физ-лицами - то в релиз должен пойти в лучшем случае 1 артифакт. В худшем случае тебе придется релизить сразу все модули а это хлопотно.

Answer 2

[Александр]

По домену, внутри домена по паттернам.

Shop
-- Factory
-- -- ...
-- Proxy
-- -- ...
Messenger
-- Factory
-- -- ...

Хотя, конечно есть паттерны которые лежат вне доменной области, например, Адаптер. Он должен находиться на отдельном слое.

Comments

[Adamos]

И потом надо тебе разобраться с тем, как в том магазине добавлена доставка СДЭКом, например - и всего-то три файлика, но в трех разных папках. Удобно...

[Xveeder]

А если файликов по 5 на каждый паттерн?
Более того, тогда становится понятно по имени пакета что для этого домена делает группа методов.

[Adamos]

Xveeder, не ЧТО, а КАК.

[Xveeder]

Adamos, отмечу себе этот момент и поисследую, спасибо. Допускаю здесь семантическую ошибку.

[Adamos]

Xveeder, собственно, если хочется снаружи класса определять его принцип работы, можно его назвать DeliveryFactory, например. Но собирать его в одной папке с PaymentFactory или StoreFactory, с которыми он ну никак не взаимодействует и никогда не будет - просто нелепо. Только потом сложнее будет поддерживать эту кучу.
При этом я вполне допускаю, что эти классы все-таки будут лежать в одной папке. Но не потому, что они все - фабрики, а по какой-нибудь более вменяемой причине.

[Xveeder]

Adamos, я, вероятно, не вполне корректно описал вопрос. Мысль как раз заключается в том, что в домене Payment создается пакет Factories внутри которого лежат разнообразные фабрики, условно, для сущности Payment. То есть, это фабрики конкретно этого домена. Не фабрики для других доменов, которые используются этим доменом, а именно фабрики только этого домена.

[Adamos]

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