D𝔇
это философия ООП, тут нет формул
Ну собственно об этом и речь. Нет смысла изначально дробить функционал на слишком мелкие блоки. Но по мере развития приложения нужно что-то выделять в отдельные классы/модули, что-то наоборот объединять итд
Size: a a a
2020 July 13
か
ещё и тыкает мне, что я не понимаю
か
Ну собственно об этом и речь. Нет смысла изначально дробить функционал на слишком мелкие блоки. Но по мере развития приложения нужно что-то выделять в отдельные классы/модули, что-то наоборот объединять итд
я не говорил о мелких
か
я говорил о кейсе, где идёт речь о приёме и отправке сообщений
か
это не мелкий функционал
か
менять код могут и спустя 5 и 10 лет, если ты работаешь в ентерпрайсе, ты просто этого никогда не знаешь, если ты не работаешь в конторе на 3.5 человека
h
для того, чтобы не нарушать этот принцип, изначально надо создавать классы, которые НЕ нарушают этот принцип
Как ты и написал "зависит от ситуации это философия …., тут нет формул"
SRP зависит от источника изменения, если изменений нет, то смысла нет.
Когда ты пишешь с нуля ты можешь примерное понимать бизнес и искать точки изменения
SRP зависит от источника изменения, если изменений нет, то смысла нет.
Когда ты пишешь с нуля ты можешь примерное понимать бизнес и искать точки изменения
か
humanoid
Как ты и написал "зависит от ситуации это философия …., тут нет формул"
SRP зависит от источника изменения, если изменений нет, то смысла нет.
Когда ты пишешь с нуля ты можешь примерное понимать бизнес и искать точки изменения
SRP зависит от источника изменения, если изменений нет, то смысла нет.
Когда ты пишешь с нуля ты можешь примерное понимать бизнес и искать точки изменения
я тебе ещё раз задаю вопрос, откуда ты знаешь, какие ситуации возникнут?
か
проекты по 10 лет некоторые живут
D𝔇
я говорил о кейсе, где идёт речь о приёме и отправке сообщений
ну я бы тоже это делил сразу, т.к. функционал неоднородный. Но могут быть ситуации, когда правильнее держать их вместе
か
ну я бы тоже это делил сразу, т.к. функционал неоднородный. Но могут быть ситуации, когда правильнее держать их вместе
всё может быть, я не говорю о всех случаях, мы говорим про бест практис
h
я тебе ещё раз задаю вопрос, откуда ты знаешь, какие ситуации возникнут?
По сути предсказания. Ты предполагаешь, что вот тут мы можем например поменять отдачу html шаблонов на json
h
проекты по 10 лет некоторые живут
А в большом проекте удобно смотреть по git log например и таскам
h
Где что менется и по каким причинам
か
humanoid
А в большом проекте удобно смотреть по git log например и таскам
ты будешь лет на 6 лет назад и копаться в логах, или с разу будешь нормально писать?
か
ты походу не работал в больших конторах, где на одном проекте сидит по 20 человек, это нормально
h
Еще ест ьпринцип про low coupling/High cohesion.
Ты пытаешься сделать везде low coupling, но он может быть только если есть High cohesion
Это относительные штуки
Ты пытаешься сделать везде low coupling, но он может быть только если есть High cohesion
Это относительные штуки
か
humanoid
Еще ест ьпринцип про low coupling/High cohesion.
Ты пытаешься сделать везде low coupling, но он может быть только если есть High cohesion
Это относительные штуки
Ты пытаешься сделать везде low coupling, но он может быть только если есть High cohesion
Это относительные штуки
пиздец
か
я ливаю
h
ты будешь лет на 6 лет назад и копаться в логах, или с разу будешь нормально писать?
Есть спец инструменты. Это как раз обычно задача тех лида