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

Question

[elmoreden]

Сталкиваюсь с разными типами ролей классов: service, repository, store, mapper. Подскажите, в какой литературе или других источниках можно почитать о ролях классов, как между ними распределить функционал и т.д.

P.S. И скажите, в чём разница между Store и Repository?

Answer 1

[Ипатьев]

Сервис - это часть модели. Класс, который реализует некую бизнес-логику, не связанную напрямую с хранилищем.
Репозиторий - часть модели, класс, который содержит методы для работы с хранилищем.
Стор - это какая-то местечковая приблуда. Из битрикса небось? Либо какие-то академические измышления, вот как в соседнем ответе. Вроде человек что-то пишет, но яснее ничего не становится.
Маппер имеет много значений. Если речь про Data Mapper, то это разделение самих данных и их отображения в БД.

Читать стандартно - Дядюшка Боб Мартин и Мартин Фаулер. Конкретно по РНР - Зандстра.

Comments

[Антон Шаманов]

Репозиторий - часть модели, класс, который содержит методы для работы с хранилищем.

не класс, а объект

Стор - это какая-то местечковая приблуда

store = storage

Если речь про Data Mapper, то это разделение самих данных и их отображения в БД.

узко мыслишь

[Иван]

Ипатьев я смотрю от вашего решения прям все человеку понятно стало)))

Answer 2

[Иван]

Литература. Хороший источник, имхо
По ddd можно погуглить порядок чтения книг, плюс допом видосы с конференций на ютубе.
"Clean Architecture" и "Domain-Driven Design" как знакомство с этим всем делом.

И скажите, в чём разница между Store и Repository?
Store - хранилище. Обычно это про паттерн состояние. Оно может содержать логику обновления состояния и взаимодействия с другими частями приложения
Repository - это такая абстракция для доступа к источнику данных, то есть где хранятся данные. Может быть файловое хранилище, может быть база данных , а иногда , если работаешь с cms/фреймами - их интерфейсы для работы с хранилищами. Как пример: репозиторий, отвечающий за получение и сохранение данных пользователей в базе данных

Comments

[elmoreden]

А можете про Store написать более подробно? Repository, как я понял, будет иметь методы, которые делают обращения к БД, либо напрямую, либо через какие-то интерфейсы фреймворков. А Store тогда что будет делать? Просто про логику обновления состояния не совсем понятно

[Иван]

elmoreden,

Repository, как я понял, будет иметь методы, которые делают обращения к БД

Репозиторий имеет два аспекта: абстракцию и конкретную реализацию.

Сама реализация репозитория как раз описывает детали. Это может включать SQL-запросы, вызовы методов ORM фреймворка или просто из файла в конкретной папке считать данные.

Repository как широкое понятие - это как раз про интерфейсы и общие методы работы с коллекциями. То есть вы как бы абстрагируетесь от всей реализации и описываете общие методы для работы с коллекциями.

А вот про Store немного запутал?

Обычно store = storage - хранилище.
Место где что-то хранится и в каком-то состоянии находится. Это может быть конкретное файловое хранилище (File Storage), может Databases Storage (mysql, mongo, sqlite), может Caching Storage (memcached), Key-Value storage (redis), может Cloud Storage (Amason s3 и т.п).
Еще может быть объектом, который содержит глобальное состояние приложения - чаще всего используется на фронтенде, это как раз я писал про состояние.

[Ivan Kudinov]

elmoreden, а по поводу распределения ответственности стоит изучить:
- SOLID: SRP (Single Responsibility Principle)
- GRASP: Information Expert, Creator, Low Coupling, High Cohesion
- В книге "Чистая Архитектура (Clean Architecture) от Роберта Мартина" также описываются SOLID и принципы ООП.

Answer 3

[mayton2019]

Поскольку топик тегирован PHP то я-бы предложил взять PHP фреймворки и смотреть как они видят себе реализацию шаблона например репозиторий. Я-бы мог рассказать о Spring Data Repository но боюсь что для PHP будут отличия и автор просто запутается.

Банда Четырех (юбилейное издание) описывает шаблоны проектирования .... эээ кажется на SmallTalk и С++. По крайней мере во Введении книги они об этом писали. Поэтому читая код надо уметь читать глазами сущности этого мира и не пугаться.

Что такое шаблон Store - я не знаю. Опять-же это специфика PHP скорее всего.

Что такое шаблон Сервис. Ну я вообще не рискнул бы его никак определять. Это КМК слишком размытое понятие и его надо срочно сузить. Хотя-бы до уровня техно-стека. Может сервис в терминологии SOAP это одно. Облачный сервис - может быть вообще другое. Короче архитекторы этих технологий будут бить друг друга здесь как епископы разных церквей друг друга за ереси.

Сервис для ООП - вообще седьмая вода на киселе. Вообще ООП надо начать и закончить на его полиморфизмах и наследованиях и поставить точку. Дальше - нет ООП. Дальше идет хаос и новые виды абстракций от вендора языка. Аннотации и аспекты и рефлексия и прочий бред.

Comments

[DollyPapper]

Обычно под сервисом имеют ввиду сервисный слой. Т.е. некий класс который реализует бизнес логику. ООП здесь никаким уже не пахнет, но это то дерьмо к которому пришли разработчики спустя столько лет :)
Мартин эти сервисы например называет UseCase

Answer 4

[Антон Шаманов]

https://ru.wikipedia.org/wiki/Design_Patterns

Answer 5

[DollyPapper]

Про репозиторий можно почитать например тут