S
Лично для меня “причина для изменения” слишком абстрактно, потому и суждения ставить на нем сложно
Size: a a a
2020 July 25
S
т.е. причина для изменений - это роль, стэйкхолдер?
SP
Дядя боб (он владелец торговой марки солид) упрощает "причину" до "источника изменений' или "на модуль должна быть одна роль которая тебе ввалит пиздюлей если ты сломал чего".
SP
Для этого надо разбираться для кого ты код пишешь и кого оно афектит
SP
Srp самый сложный принцип в этой пятерке. Как раз в силу того что ответ соблюдается принцип или нет привязан к контексту задачи и потоку изменений требований
SP
Формулировка простая и абстрактная, не то что lsp который в целом самый простой принцип ибо формализован хорошо
SP
Но в целом мне нравится объяснять людям что главное в солид open close а все остальные принципы помогают к нему придти
SP
Цель - уменьшить вероятность возникновения каскада изменений. Мол что б небыло "потрогал тут и понеслось код менять".
SP
Если применяя солид ты получил кучу абстрактных фабрик и миллион зависимостей - скорее всего ты понял солид не совсем так
S
Srp самый сложный принцип в этой пятерке. Как раз в силу того что ответ соблюдается принцип или нет привязан к контексту задачи и потоку изменений требований
я так понимаю, что более менее формальных правил выявления причины для изменения не существует? хотя бы из опыта, без научных работы/статей
S
1. Encrypt decrypt интерфейсы для шифрования чего нибудь. Класс будет иметь одну причину для изменений и две роли.
2. Когда интерфейсы класса никак не пересекаются по смыслу. Например если класс user имплементит интерфейсы merchant и customer и контракт не подразумевает никаких пересечений. У нас причины менять код всегда будут разными и имеет смысл это дело разделить.
2. Когда интерфейсы класса никак не пересекаются по смыслу. Например если класс user имплементит интерфейсы merchant и customer и контракт не подразумевает никаких пересечений. У нас причины менять код всегда будут разными и имеет смысл это дело разделить.
и еще по Примеру 1. Что нам дает разделение интерфейса на 2 здесь, вместо одного, с двумя публичными методами?
VS
пример не очень удачный с encrypt/decrypt
если рассмотреть пример с человеком, который и девелопер и qa, то интерфес девелопера и интерфейс qa можно реализовать в двух разных классах (т.е. это будут два разных человека)
и в зависимости клиентского кода ты можешь передавать только интерфейс qa, если тебе в этом клиенте требуется, чтобы человек только протестировал что-то (а не разрабатывал)
если рассмотреть пример с человеком, который и девелопер и qa, то интерфес девелопера и интерфейс qa можно реализовать в двух разных классах (т.е. это будут два разных человека)
и в зависимости клиентского кода ты можешь передавать только интерфейс qa, если тебе в этом клиенте требуется, чтобы человек только протестировал что-то (а не разрабатывал)
SP
пример не очень удачный с encrypt/decrypt
если рассмотреть пример с человеком, который и девелопер и qa, то интерфес девелопера и интерфейс qa можно реализовать в двух разных классах (т.е. это будут два разных человека)
и в зависимости клиентского кода ты можешь передавать только интерфейс qa, если тебе в этом клиенте требуется, чтобы человек только протестировал что-то (а не разрабатывал)
если рассмотреть пример с человеком, который и девелопер и qa, то интерфес девелопера и интерфейс qa можно реализовать в двух разных классах (т.е. это будут два разных человека)
и в зависимости клиентского кода ты можешь передавать только интерфейс qa, если тебе в этом клиенте требуется, чтобы человек только протестировал что-то (а не разрабатывал)
Можно и нужно ли это разные вещи
SP
пример не очень удачный с encrypt/decrypt
если рассмотреть пример с человеком, который и девелопер и qa, то интерфес девелопера и интерфейс qa можно реализовать в двух разных классах (т.е. это будут два разных человека)
и в зависимости клиентского кода ты можешь передавать только интерфейс qa, если тебе в этом клиенте требуется, чтобы человек только протестировал что-то (а не разрабатывал)
если рассмотреть пример с человеком, который и девелопер и qa, то интерфес девелопера и интерфейс qa можно реализовать в двух разных классах (т.е. это будут два разных человека)
и в зависимости клиентского кода ты можешь передавать только интерфейс qa, если тебе в этом клиенте требуется, чтобы человек только протестировал что-то (а не разрабатывал)
Почему неудачный?
SP
Sergey
и еще по Примеру 1. Что нам дает разделение интерфейса на 2 здесь, вместо одного, с двумя публичными методами?
Смотри принцип сегрегации интерфейсов
SP
И dependency inversion
SP
Если коротко - сколько надо интерфейсов и каких решается исходя из того кто и как эти интерфейсы юзает
SP
Хочется более "конкретных" принципов которые можно рассматривать в разрезе проектирования а не рефакторинга - смотри grasp
АГ
запустил проект на ларавеле - composer.json что-то не видать. что-то не так с этим. классно, но не полноценный проект в вебе