Как выбирать направление архитектуры ООП приложения?

Question

[Urukhayy]

Если требуется реализовать какое-то приложение, то какой из множества способов архитектуры выбирать?
Даже какое-то событие в этом приложении (event) можно реализовать и как отдельный класс-синглтон, и как просто поле в другом классе, и как enum, и как полиморфный класс для множества событий.
Есть ли практики, которым следует придерживаться, чтобы сделать правильную и простую архитектуру?

Answer 1

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

и как отдельный класс-синглтон

Зачем? Зачем сингелтон? Ответте на вопрос когда это нужно?

Есть ли практики, которым следует придерживаться, чтобы сделать правильную и простую архитектуру?

- Разделение ответственности - важный принцип инженерного дела в принципе.
- Принципы SOLID - хорошо дают понять как работать с зависимостями и делать декомпозицию системы. Сильно пересекается с инкапсуляцией, полиморфизмом и разделением ответственности.
- Паттерны GRASP - эдакая смесь принципов и паттернов, описывают нюансы цикла жизни объектов и их взаимодействия друг с другом.
- Закон Деметры - про инкапсуляцию.
- CQRS - подход по разделению операций записи и операций чтения. Естественно подход такой не работает если вам надо реализовать атомарную запись и чтение, но это минимальный набор задач.
- Рефакторинг. Он нужен всегда. Его нужно делать по чуть-чуть когда видно что "уже мешает" или "можно было сделать лучше". Ну то есть это не переписывание всего и вся большими кусками, а маленькие изменения которые с течением времени эволюционно меняют архитектуру проекта. Возможно только если код покрыт тестами, это отдельная жирная тема.

Не нужно знать "архитектуры", они являются лишь результатом соблюдение принципов. И уж тем более "паттерны" это лишь элементы архитектуры. Не нужно на них зацикливаться, это лишь словарь.

https://en.wikipedia.org/wiki/Category:Programming...

Comments

[Urukhayy]

Возможно, такой класс потребуется для сущности, которую нужно создать единожды. К примеру: Доска для игры в шашки, или партия.

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

Urukhayy: "сингелтон" нужен только и только тогда, когда вам критически важно, чтобы небыло никаких возможностей в многопоточном приложении дать доступ к ограниченным ресурсам. Например - вы открыли порт и должны дать доступ к нему для всех. И все просто его используют, а сам класс описывающий взаимодействие с портом сам разруливает кому что можно и когда. Причем я даже не уверен что при наличии других подходов у нас все еще остается необходимость в этом подходе. По дефолту мы должны игнорировать сингелтоны и использовать их только если не можем придумать ничего лучше (и мы реально думали).

То есть "события" - это просто объекты. Точно так же как и сущности. Не стоит так же забывать о объектах-значениях. А еще есть языки, у которых есть функции. И есть функции высшего порядка, которые могут выступать как объекты. А может быть у языка нет классов, но есть возможность задавать свои типы другим способом (javascript например).

И по сути, нужно попытаться абстрагироваться и понять общие концепции вроде "типы данных", "инварианты" и т.д.

Есть еще книжки вроде "предметно-ориентированное проектирование" от Эрика Эванса. Они не дают полный ответ конечно, но позволяют немного "разложить все в голове".

Мое личное мнение - отсутствие понимания структурного программирования у людей, которые лезут в ООП, это сильный минус. До всяих там смолтоков и ООП уже были классы (simula67), которые являлись лишь способом создать "структуру", изолирующую стэйт.

Answer 2

[bnytiki]

Простите, вы только что написали нечто вроде -

Как лечат людей, как выбирают какие лекарства давать, какие назначать анализы.
Этому люди учатся в медицинских ВУЗах годами, затем интернатура, ординатура...

Практики наверно есть.
Но я их не знаю.

После 20 лет опыта это все происходит так:

Ну ты просто представляешь что там происходит внутри программы и понимаешь как нужно разделить на части и на какие именно части и к чему приведет выбор того или иного варианта.

Просто логически размышляешь - и решаешь.