Liskov Substitution для конструкторов

Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті.

Добрый день!

Однажды на собеседовании мне задали вопрос: является ли нарушением LS принципа, возможность создавать конструкторы c неоднородными параметрами в PHP?

Я долго колебался пытаясь построить логику в голове и сказать заветное «да/нет». В конечном итоге я сказал что «нет». Иначе, мне это в предыдущих проектах встретилось бы. Как минимум в мануалах по «хорошим практикам».
Я долго думал на эту тему, складывал «за и против» в контесте проектов в которых работал,и у меня в голове 50/50 баланс.

Только что наткнулся на такой пост(закрыт админами стака, за то что ответы базируются на личных мнених):
stackoverflow.com/...ov-substitution-principle

Вопрос: А как вы считаете, господа, «любители хороших практик», это нарушение или нет?

Ctrl + Enter

Valentin Nechayev архімаггриб в Дарницькі печери 18.10.2016 14:58

Так как гугление по фразе «конструкторы с неоднородными параметрами» приводит только на данную страницу форума, я прошу расшифровать этот странный термин. После этого можно будет ответить по сути.

Если же попытаться это понять, как то, что должен ли быть у каждого подкласса конструктор с какими-то конкретными параметрами и соответствующим поведением — мой ответ: обязан тогда и только тогда, когда это требование почему-то входит в контракт базового класса согласно ТЗ. Иначе — в сад. На то они и разные подклассы, чтобы и создаваться по-разному.

Ну а по админ. вопросам коллега Пение уже ответил, целиком поддерживаю.

Відповісти

Підтримати

Андрей Литвинов C Señor 17.10.2016 18:34

Принцип же о заменяемости объектов, а не об их конструкторах. Используйте абстрактные фабрики (фабрик фабрик).

Alexander Baranetsky Software engineer 17.10.2016 19:34

Используйте абстрактные фабрики (фабрик фабрик).

Если это 2-3 ветвления логики, то применение фабрики привет к нарушению принципа KISS. :)

Андрей Литвинов

Gennady Dogaev full-stack web developer (freelance) 17.10.2016 13:26

А разница? Глупый теоретический вопрос, слабо соотносящийся с практикой. Код в определенный момент или пахнет или нет. Это как-то видно сразу. И пахнуть может в том числе код, формально соответствующий великим теоретическим принципам.

Grez 18.10.2016 07:32

Какраз модное нынче фп утверждает, что код соответствующий принципам это прям серебрянная пуля, даже если пахнет.

Gennady Dogaev

anonymous 17.10.2016 03:28

Олексій Пєніє 15.10.2016 18:21

Разумеется, не является. И здесь всем, если честно, глубоко начхать на твой ответ да/нет, здесь важна аргументация. То есть знаешь ли ты этот принцип.

Объясню на примере: ты продаёшь квартиры. И друг попалась квартира, в которой планировка ещё не сделана, и она будет делаться по желанию клиента. Вопрос: ты сможешь добавить эту квартиру на свой сайт по продаже квартир, при условии что ты простой менеджер, то есть не станешь переделывать функционал сайта? Ответ: да без проблем, даже глазом не моргнёшь.

Это и есть принцип Substitution: не нарушает ли потомок ту модель поведения, которую ожидают от его родителей и родственников.

PS. Это идиотизм спрашивать такие глупости. Практически все программисты кроме некоторых очень индийских гениев, так делают, и понятия не имеют что обязаны какой-то тёте Лисков за обнаруженный ею принцип здравого смысла. Естественно, этот принцип был и до неё, потому что он в самой основе естественных языков. Люди, знаешь ли, описывали объекты задолго до программирования.

Alexander Baranetsky Software engineer 15.10.2016 22:35

Смотри, для меня LS это чистый полиморфизм, минус всякие «хитрости» в коде коде.
То есть если в одном из подтипов есть метод в котором нестандартный throw (например), либо в цикле нужно использовать «if instanceof» что бы вызвать метод для кагото из поддтипов с отличимым параметром. Для меня это нарушение принципа. По сути дела если ты в коде используешь instance of — это уже какойто «нестандартный» полиморфизм.

Олексій Пєніє

DNA Exp 15.10.2016 23:05

В Lisp’e вообще типов раз два и обчелся. Везде списки и работа с списками. Читай сплошной InstanceOf. И тем неменее в плане SOLID этот язык на голову выше всяких типизированых ПХП. Еще раз, не путайте правильную архитектурную декомпозицию с деталями реализации на конкретных языках.

Alexander Baranetsky

Олексій Пєніє 16.10.2016 04:03

Есть у бизнеса злейший враг: бюрократия. Она беленькая и пушистенькая, но страшнее зверя нет.
В чём суть: все эти теоретики прочитали 2 умных книжки за жизнь — пропись для первого класса, и ту по которой тебя спрашивают. И не написали ни строчки боевого кода.

А с точки зрения боевого кода — у него только 2 критерия:
1) Чтобы компьютер понимал, что ты от него хочешь и мог это выполнить.
2) Чтобы люди понимали, чего ты от него хочешь, в том числе ты сам. И чтобы когда надо подправить, допилить, или найти багу — это не вызывало затруднений.

Язык программирования — это посредник между компьютером и человеком. Так вот, БЮРОКРАТ таким посредником не является. Всё что может понять бюрократ — это другого бюрократа в своём тёплом ламповом бюрократическом мирке бюрократического дерьма, а пересади в другую комнату — и уже не лев-толстой.

Хочешь быть программистом — вызубри методологию!

Alexander Baranetsky Software engineer 16.10.2016 12:11

И не написали ни строчки боевого кода.

Человек который меня спрашивал. Похоже, написал много кода. И не один мануал/книжку прочитал.

Олексій Пєніє 17.10.2016 00:03

Тогда бы не спрашивал. Как правило такое спрашивают манагеры, которые если и кодили, то очень немного, и разумеется низкопробного кода.
Понимаешь, чтобы спрашивать только то что нужно — мало самому выучить и книжку почитать. Нужно ЗАБЫТЬ львиную долю того что выучил, и оно оказалось не нужным. И только то что по факту нужно, притом нужно многократно и каждый день — только это и спрашивать.

Иначе говоря, 99+% того что в книжках — тупо мусор. В коде оно короче и понятнее. Из того <1% который в остатке — 98% ты не будешь помнить, а лишь знать где взять при случае. То есть база знаний, которая должна быть всегда под рукой. И только те 0,02% которые в постоянной эксплуатации — нужно знать.

Джун от сеньйора отличается не тем, что он меньше знает. Наоборот, знает он в разы больше. Просто знает не то. И если этот джун пошёл менеджером — то он так и остался джуном как кодер, и спрашивает по уровню и количеству знаний джунов. И его фильтр проходят только те, кто кто тоже остался джуном — знает много того, что не нужно в работе.

Так и рождаются 23-летние синьйоры. Есть то, что бюрократия умеет лучше всего — актёрское мастерство. Вот именно создать впечатление что человек много знает, пустить пыль в глаза — это то чем они занимаются.

Простой вопрос бюрократа: на какие 3 вида делятся транзакции?
Правильный ответ: об этом знает только тот, кто делит. В действительности «транзакция» — это огромный класс задач, объединённых общим признаком: задача должна быть выполнена целиком, либо приняты какие-то действия в случае неудачи (что опять же, не обязательно). Больше никаких сходств нет. А формально можно найти 100500 типов, видов, и классов транзакций.

И так чуть ли не по любому вопросу- реальное выполнение кода компьютером, и те задачи которые ему ставятся реальными людьми — очень далеки от того бреда, который навыдумывали теоретики от программирования. И так не только в программировании, но в программировании особенно. Из-за того что информации о программировании в принципе в мире больше, чем всей остальной вместе взятой. И тем меньше её полезность, потому что способности человека ею пользоваться остаются на том же уровне.

DNA Exp 15.10.2016 16:06

Я думаю когда Барбара формулировала принцип подстановок в далеком 87м году, она ничего не знала о ПХП с их неоднородными конструкторами. Это архитектурный принцип и он подразумевает что вы можете провести в своем коде ряд сценариев — подстановок среди правильно пронаследованых классов. Если вы это все еще можете сделать используя в том числе среди классов с неоднородными конструкторами, то почему бы и нет. Вы не нарушаете этот принцип.
Другой вопрос, что тот кто без острой необходимости использует в коде такие виды конструкторов, вероятно о принципе подстановок не задумывается и скорей всего рано или поздно в таком коде будет нарушен не только LSP.

Jorzchyk Pushysty 15.10.2016 15:25

Является ли конструктор методом создаваемого объекта? Чтобы к нему применялся LSP.

В исходной формулировке: is the way to create an object a property provable about the created object?
en.wikipedia.org/...ov_substitution_principle

Liskov Substitution для конструкторов

13 коментарів

Підписатись на коментарі