M
Включение всей логики в один класс сущности это нарушение srp, низкая связность функций с классом.
Size: a a a
2020 May 13
DT
spr вообще не про классы
АС
сущность - вообще не про логику
на чем давно пора бы закончить этот бессмысленный разговор, который тут тлеет уже третий день
на чем давно пора бы закончить этот бессмысленный разговор, который тут тлеет уже третий день
VM
Включение всей логики в один класс сущности это нарушение srp, низкая связность функций с классом.
а что если сделать несколько сущностей так, что бы методы с логикой были тесно связаны с этой сущностью?
M
spr вообще не про классы
А про что?
DT
про ответственность
M
про ответственность
У одного класса одна ответственность. Про это
V
У одного класса одна ответственность. Про это
В языках без классов значит нет srp?
DT
В языках без классов значит нет srp?
конечно нет, это же про классы
VT
про ответственность
ну тоже спорно
про единственный источник изменений звучит конкретнее
про единственный источник изменений звучит конкретнее
DT
так а изменения откуда идут? от ответственностей
ЕР
Включение всей логики в один класс сущности это нарушение srp, низкая связность функций с классом.
Не будет там низкий cohesion, если сущности делать по логике а не по "ну вот на экране заказ и сущность будет заказ"
VT
так а изменения откуда идут? от ответственностей
изменения идут от заказчиков
я к тому, что ответственность это слишком общее слово
я к тому, что ответственность это слишком общее слово
DT
если ответсвенности верно напилены, то и изменения относятся к каждой ответственности
ЕР
Так можно один сервис сделать и все в него положить. То же самое будет.
И в итоге не понятно, какой сервис за что ответственен, а поля сущности по прежнему публичные и мутабельные
VT
если ответсвенности верно напилены, то и изменения относятся к каждой ответственности
правильно делай - правильно будет?)
DT
правильно делай - правильно будет?)
точно) я ваще хз о чем спор😁
DT
это ж очевидно)
VT
ща, код без багов только закончу писать и сразу ответственности правильно разделю )