Такое поведение сущностей, а именно Active Record, считается антипаттерном по ddd, также противоречит философии большинства orm, но имхо если число хранилищ не превышает 1, то городить что то сверх простейшего ar не имеет смысла
А Ява так 10 из 10. Первоначальный тейк был о том, что шарп привяжет пользователя к винде. А оказалось, что не привяжет. Теперь вы говорите, что шарп ну это перебор просто потому что. Жирно, жирно
Наследование возможно и вне ооп. Архитектура приложений может реализовываться в рамках разных парадм в зависимости от ситуаций. Например, если есть ограниченный набор данных и предлагается реализовывать различные функции над этими данными, то это идеальная задача для процедурного программирования, и наоборот если имеется куча данных и ограниченный набор функций над этими данными, то это задача для ооп. Решить эти задачи можно в любой из парадигм, но реализовав первую задачу в ооп парадигме при добавлении функции над данными придется реализовать функции всем наследникам, а если вторую задачу решить в процедурном стиле, то при введении очередного типа данных придется изменять все функции над набором данных. В рамках чистой архитектуры рассматриваются модули, а не классы, а модулем может быть хоть класс, хоть файл, хоть сервис или любая другая программная единица. Чистая архитектура не про ограничения и правила ради усложнений, а наоборот чтобы люди писали просто и понятно в рамках реализуемой задачи, и не в коем случае не пытались натянуть сову на глобус. От задачи к задаче всё разное. Чистая архитектура это некое философское течение, по типу "не что, а как"
А почему все классы должны быть стабильные? Удачи отредачить проект, где все классы и модули стабильные)) Нестабильность классов или модулей позволяют их изменять или заменять не боясь, что изменится всё что находится уровнем выше. Иначе в ооп парадигме это считай нужно будет править всех наследников, а потом ещё и тестировать, а потом ещё и разворачивать заново. На практике это выражается допустим в различных реализациях какого нибудь клиента для различных заказчиков. Или же как часто бывает на начальных этапах неизвестно о низкоуровневых деталях проекта, поэтому вместо них лепят абстракцию и делают временную реализацию этого интерфейса до выяснения обстоятельств, чтобы банально проект запустить.
Хотя это конечно не относится к одноразовым и лёгковесным проектам с небольшим набором критических бизнес правил. Если рассматривать в таком ключе, то классы или модули могут быть хоть все стабильные.
Ммм вкуснятина какая
Такое поведение сущностей, а именно Active Record, считается антипаттерном по ddd, также противоречит философии большинства orm, но имхо если число хранилищ не превышает 1, то городить что то сверх простейшего ar не имеет смысла
А Ява так 10 из 10. Первоначальный тейк был о том, что шарп привяжет пользователя к винде. А оказалось, что не привяжет. Теперь вы говорите, что шарп ну это перебор просто потому что. Жирно, жирно
На костыль какой то похоже.
Можете поделиться проектом?
По моему шенон со своей формулой энтропии уже доказал почему у бита должно быть именно 2 значения.
Никакой корреляции между религией и iq нет. Начните читать что то кроме паблика "Атеист" ВКонтакте.
Вы оперируете в контексте единой ответственности функциями, хотя главное это данные, с которыми работают функции. Вся соль в связности классов.
Наследование возможно и вне ооп. Архитектура приложений может реализовываться в рамках разных парадм в зависимости от ситуаций. Например, если есть ограниченный набор данных и предлагается реализовывать различные функции над этими данными, то это идеальная задача для процедурного программирования, и наоборот если имеется куча данных и ограниченный набор функций над этими данными, то это задача для ооп. Решить эти задачи можно в любой из парадигм, но реализовав первую задачу в ооп парадигме при добавлении функции над данными придется реализовать функции всем наследникам, а если вторую задачу решить в процедурном стиле, то при введении очередного типа данных придется изменять все функции над набором данных. В рамках чистой архитектуры рассматриваются модули, а не классы, а модулем может быть хоть класс, хоть файл, хоть сервис или любая другая программная единица. Чистая архитектура не про ограничения и правила ради усложнений, а наоборот чтобы люди писали просто и понятно в рамках реализуемой задачи, и не в коем случае не пытались натянуть сову на глобус. От задачи к задаче всё разное. Чистая архитектура это некое философское течение, по типу "не что, а как"
А почему все классы должны быть стабильные? Удачи отредачить проект, где все классы и модули стабильные)) Нестабильность классов или модулей позволяют их изменять или заменять не боясь, что изменится всё что находится уровнем выше. Иначе в ооп парадигме это считай нужно будет править всех наследников, а потом ещё и тестировать, а потом ещё и разворачивать заново. На практике это выражается допустим в различных реализациях какого нибудь клиента для различных заказчиков. Или же как часто бывает на начальных этапах неизвестно о низкоуровневых деталях проекта, поэтому вместо них лепят абстракцию и делают временную реализацию этого интерфейса до выяснения обстоятельств, чтобы банально проект запустить.
Хотя это конечно не относится к одноразовым и лёгковесным проектам с небольшим набором критических бизнес правил. Если рассматривать в таком ключе, то классы или модули могут быть хоть все стабильные.