Какую цель преследует публикация? А можно еще публикации про дедушек, бабушек, школьников, студентов, людей с нетрадиционной ориентацией, семейных людей, путешествующих, с рыжим цветом волос, и чтоб обязательно все в айти?
Это тема отдельного разговора, но такой подход не сработает — нельзя обмануть естественный отбор, а потом за счет физ.нагрузок. Если научно-технический прогресс позволяет выжить и успешно существовать нежизнеспособным или маложизнеспособным особям, это не значит, что в них будет заложен тот же боевой потенциал в виде здорового тела и духа.
Лично на мой взгляд, в php достаточно фич из разряда makeSomethingLikeFooButInAnotherWay. Если можно удержаться от «двусмысленности», то лучше так и поступить.
Во-первых, старайтесь никогда не приводить примеры абстрактных коней в вакууме, так как они за собой влекут точно такие же выводы.
Во-вторых, Вы на основе чего программируете? Реализации? Не ведет это «к частично более полному соблюдению LSP». Если сигнатура гласила Razor::shave(Beard $beard), то, для возможности побрить что-то еще, необходимо не глушить сигнатуру в дочернем классе, а пересматривать решение на уровне интерфейса. Почему не, к примеру, Razor::shave(ShaveableInterface $hairySurface)?
Вы не подумайте, я на Вас бочку не качу)
Просто не в состоянии своё недоумение выразить в полной мере касательно «parameter-no-type-variance». Только и просится фраза «Зачем?!».
Я не могу себе придумать практическое применение этого вброса, который почти наверняка будет вести к нарушению LSP и OCP. Хочу схватиться за голову и бегать…
Мне не в первый раз доводится слышать «пусть понимают, а не копируют». И не в первый раз я с этим не согласен. Люди так учатся и это нормально. Дети произносят слова, но могут даже не понимать их настоящего смысла(словообразование, заимствованность, эмпирическая составляющая). И это может сохраняться до самого что ни на есть старческого возраста.
Единственный вопрос — цена реализации и цена сопровождения.
Если не учитывается вопрос цены, то это все просто «обезъянка видит — обезъянка делает».
Вопрос цены учитывается всегда. И, если смотреть дальше собственного носа, цена всегда растет, пусть даже и не самым очевидным путем. А обезьянки — это геометрический рост цены.
И дайте четкую метрику для понятия «Single Responsibility Principle». Атомараная функция? Доменная область? Бизнес-процесс?
После этого можно будет четко сказать — нарушено или нет.
А «может свидетельствовать» это все фигня.
В случае с SOLID, все принципы, кроме I, накладывают границы, а не дают какие-то рекомендации. Выход за эти границы — есть нарушение принципа. Это и есть те самые «четкие требования».
Вот то, что Вы и Ваша команда понимают под границами принципов, и является «четкой метрикой». Разумеется, при условии того, о чем я сказал в самом верху: каждый должен получить базу и на основе этой базы уже формировать командное восприятие.
Какой-то очень сомнительный аргумент. Сначала программистам говорят «не надо создавать divine классы». Потом к этому добавляют SRP и только потом отпускают ломать дрова на собственном опыте. Потому как, в противном случае, человек будет бродить в потьмах. Рано или поздно он для себя откроет те истины, которые, как он обнаружит, были раскрыты и задекларированы задолго до него, но к чему затягивать это «рано или поздно»?
Вы же понимаете, что такие утверждения используются для «снижения порога входа»?
Эти правила лишь обобщения, ведущие примерно к одному результату — улучшению качества кода.
Если проводить аналогию, Вы ведь не будете рассказывать восьмилетнему ребенку, как происходит пиролиз на примере ожога? Почти наверняка Вы объясните, что огонь опасен и, если до него дотронуться, возникнет боль. И это будет ценный совет, хоть он и не раскрывает полной картины.
прямо аларм о том, что начал прорисовываться антипаттерн telescoping constructor
Лично на мой взгляд, в php достаточно фич из разряда makeSomethingLikeFooButInAnotherWay. Если можно удержаться от «двусмысленности», то лучше так и поступить.
Во-вторых, Вы на основе чего программируете? Реализации? Не ведет это «к частично более полному соблюдению LSP». Если сигнатура гласила Razor::shave(Beard $beard), то, для возможности побрить что-то еще, необходимо не глушить сигнатуру в дочернем классе, а пересматривать решение на уровне интерфейса. Почему не, к примеру, Razor::shave(ShaveableInterface $hairySurface)?
Вы не подумайте, я на Вас бочку не качу)
Просто не в состоянии своё недоумение выразить в полной мере касательно «parameter-no-type-variance». Только и просится фраза «Зачем?!».
Вопрос цены учитывается всегда. И, если смотреть дальше собственного носа, цена всегда растет, пусть даже и не самым очевидным путем. А обезьянки — это геометрический рост цены.
В случае с SOLID, все принципы, кроме I, накладывают границы, а не дают какие-то рекомендации. Выход за эти границы — есть нарушение принципа. Это и есть те самые «четкие требования».
Вот то, что Вы и Ваша команда понимают под границами принципов, и является «четкой метрикой». Разумеется, при условии того, о чем я сказал в самом верху: каждый должен получить базу и на основе этой базы уже формировать командное восприятие.
Эти правила лишь обобщения, ведущие примерно к одному результату — улучшению качества кода.
Если проводить аналогию, Вы ведь не будете рассказывать восьмилетнему ребенку, как происходит пиролиз на примере ожога? Почти наверняка Вы объясните, что огонь опасен и, если до него дотронуться, возникнет боль. И это будет ценный совет, хоть он и не раскрывает полной картины.