Типичная перегрузка методов, которая в PHP может быть ещё и гибче, чем, например в Java, поскольку не нужно объявлять отдельную версию метода на каждую возможную комбинацию параметров, а можно их проанализировать по классу и типу в произвольном порядке. Разумеется и все минусы и плюсы как следствие этого подхода — анализ на этапе выполнения, а не на этапе трансляции в байткод.
И что в этом простого? Если я для своего проекта выберу другой язык — популяризации этого языка это поспособствует мало, а вот я огребу все недостатки низкой популярности этого языка — отвратная документация, отсутствие вменяемого сообщества, отсутствие соответствующего предложения на рынке труда. Хорошо, если проект — крупный и расчёт изначально идёт на то, что труд высококлассного программиста на порядки дешевле затрат на железо, всё окупится. Крупные проекты, собственно, так и поступают. Но если проект небольшой, специалисты на него нужны недорогие, то простотой здесь не пахнет ну никак. Небольших проектов значительно больше, чем крупных. Энтузиастов, готовых облагораживать за свой счёт индустрию — не много.
По моему скромному мнению, PHP вообще развивается быстрее, чем альтернативные языки откусывают долю от рынка.
«инкапсуляция — это скрытие реализации за интерфейсом» — мы, собственно, разошлись вокруг этого пункта. Если Вы с ним согласны, то о чём мы тогда спорим?
Давайте так — начнём с продолжим дискуссию определением терминов. Поскольку здесь их итак уже каждый использует достаточно выборочно. Вполне допускаю, что Ваше определение на уровне аксиомы будет включать, что нечто является нарушением чего-то, о чем спорить в таком случае будет абсолютно бессмысленно и Вы будете по определению правы. Мне же останется настаивать только на другом определении в рамках которого буду прав я.
Но всё же ещё раз напомню пропущенную часть моего утверждения: класс может поменяться в реализации в любой момент. Именно поэтому прямой доступ к публичному полю не эквивалентен доступу к приватному полю через геттер и сеттер, получающий/устанавливающий это поле без дополнительных действий. В случае геттера/сеттера пространство возможных реализаций шире, чем просто чтение и установка поля и независимо от внешнего кода, поэтому инкапсуляция не нарушена.
Именно что в результате растягивания круг перестаёт быть кругом. Круг — это не отдельная независимая сущность, а лишь частный случай возможного состояния эллипса. Круг не перестаёт быть эллипсом, сохраняя все его свойства. Методы круга не должны нарушать логику поведения эллипса. Если эллипс менял пропорции осей, то и круг должен их поменять, потеряв при этом свойства круга.
Известные мне ОО языки не позволяют реализовать приобретение и потерю свойств (смену класса) автоматически, поэтому придётся либо решать через Immutable реализацию, либо делегировать поведение отдельному компоненту объекта, но в любом случае потребуется создать соответствующую инфраструктуру диспетчеризации свойств, подбирающую новую необходимую реализацию при изменении состояния объекта. И в этом случае, как я писал выше, возврат объекта другого класса — тоже нетривиальная задача, если нужно соблюсти принцип глясящий, что код не должен знать о всех возможных реализациях интерфейса, но только сам интерфейс.
Да, я тоже так подумал :-)
Но всё же статья — очень эмоционально и посредством достаточно спорных обобщений выражает этот смысл. Впрочем, сама завязавшаяся вокруг статьи дискуссия того стоила. По крайней мере для себя я нашёл много интересных и полезных, как мне кажется, идей и замечаний.
В конце концов, в определении полиморфизма нет ни слова о методах. Технически, спецификация объекта «стул» описывает огромный набор реализаций стульев, ни один из которых никаких функций не выполняет (функции «сидеть» и «кататься на стуле» относятся уже к вам, а не к стулу).
Возможно Вы выбрали неудачный пример со стулом, но мне кажется, что неверен всё-таки сам изначальный посыл, что свойство не имеет никакого отношения к методам. На этом фоне интересно отметить, что в русском языке состояния передаются глаголами — стоит, лежит, падает. То, что мы используем как прилагательные — большой, белый — является отдельными значениями свойств, а сами свойства задаются через «методы» быть (в русском языке опускаемый глагол в настоящем времени, вследствие чего неочевидный), стать. Был белым, стал серым. Причём вполне закономерно, что стал серым в результате внешнего воздействия — кто-то сделал серым. У обоих объектов методы: и у активного, и у пассивного, что в нашем языке выражается через действительный и страдательный залоги. А состояния — результаты выполнения методов.
Также хочу заметить, что в действительности нет никаких стульев или ещё каких классов — это не более чем абстрактные названия для конфигураций волновых пакетов в нашем клеточном автомате, который мы называем реальностью.
Поэтому ООП — это всего лишь проекция нашего способа мышления на языки программирования. Независимо от того, поверх процедурной парадигмы (что мы и привыкли ООП называть) или поверх функциональной (что видим в том же Хаскеле, который не называют ООП языком). Так что по итогу — либо и то и другое называть ООП, либо отказываться от самого термина в его нынешнем употреблении.
Но тут ничего не поменяется: термин ООП — давно уже превратился в бренд.
Тут всё сложнее. Дело в том, что данный частный случай — это не уменьшение интерфейса, а его увеличение, поскольку круг по прежнему сохраняет все свойства эллипса и при определённой модификации он просто лишается своих частных свойств, что прекрасно отражено в примере с Immutable реализацией.
А вот смена логики работы методов stretch..., когда вместо растягивания по одной оси круг начинает растягиваться по двум осям — действительно неправомерна. Для изменения двух осей у круга должен быть отдельный метод вроде stretchRadius. Тогда принцип подстановки Лисков нарушен не будет.
Потешить своё самолюбие. «я десять лет как обычный человек пользовался PHP и вдруг открыл для себя _______ (нужно вписать) — Свет Истины озарил меня!». Неофиты — самые ярые фанатики и проповедники.
Без его ведома? Мне кажется он, как автор библиотеки, немного больше участвует в планировании фич и за ним — решающее слово, как оно будет.
Но скорее всего — какое-то legacy, надо будет поинтересоваться историей развития раньше версии 1.3
Однако авторы подобных статей — не конструктивны. На тему того, что PHP плох — вылито уже прилично помоев. Но ещё никто не придумал, как внедрить в инфраструктуру веб лучший язык. А без этого все подобные статьи — неуместный троллинг и пережёвывание одного и того же. Впрочем, именно эта статья наверно должна была быть написана, переведена и прочитана каждым — титанический труд собрать всё это вместе и систематизировать. Надеюсь это поможет как-то изменить ситуацию со временем — то ли в сторону развития PHP как языка, то ли в сторону популяризации Ruby или Python'а.
Логично, но не до конца.
Написать в параметрах i, v — очевидней и короче, чем использовать this. Тем более, что this — всегда приходится использовать с оглядкой — в той ли области видимости мы находимся?
array_filter($array)
array_filter($callback, $array)
Типичная перегрузка методов, которая в PHP может быть ещё и гибче, чем, например в Java, поскольку не нужно объявлять отдельную версию метода на каждую возможную комбинацию параметров, а можно их проанализировать по классу и типу в произвольном порядке. Разумеется и все минусы и плюсы как следствие этого подхода — анализ на этапе выполнения, а не на этапе трансляции в байткод.
И что в этом простого? Если я для своего проекта выберу другой язык — популяризации этого языка это поспособствует мало, а вот я огребу все недостатки низкой популярности этого языка — отвратная документация, отсутствие вменяемого сообщества, отсутствие соответствующего предложения на рынке труда. Хорошо, если проект — крупный и расчёт изначально идёт на то, что труд высококлассного программиста на порядки дешевле затрат на железо, всё окупится. Крупные проекты, собственно, так и поступают. Но если проект небольшой, специалисты на него нужны недорогие, то простотой здесь не пахнет ну никак. Небольших проектов значительно больше, чем крупных. Энтузиастов, готовых облагораживать за свой счёт индустрию — не много.
По моему скромному мнению, PHP вообще развивается быстрее, чем альтернативные языки откусывают долю от рынка.
начнём спродолжим дискуссию определением терминов. Поскольку здесь их итак уже каждый использует достаточно выборочно. Вполне допускаю, что Ваше определение на уровне аксиомы будет включать, что нечто является нарушением чего-то, о чем спорить в таком случае будет абсолютно бессмысленно и Вы будете по определению правы. Мне же останется настаивать только на другом определении в рамках которого буду прав я.Но всё же ещё раз напомню пропущенную часть моего утверждения: класс может поменяться в реализации в любой момент. Именно поэтому прямой доступ к публичному полю не эквивалентен доступу к приватному полю через геттер и сеттер, получающий/устанавливающий это поле без дополнительных действий. В случае геттера/сеттера пространство возможных реализаций шире, чем просто чтение и установка поля и независимо от внешнего кода, поэтому инкапсуляция не нарушена.
Известные мне ОО языки не позволяют реализовать приобретение и потерю свойств (смену класса) автоматически, поэтому придётся либо решать через Immutable реализацию, либо делегировать поведение отдельному компоненту объекта, но в любом случае потребуется создать соответствующую инфраструктуру диспетчеризации свойств, подбирающую новую необходимую реализацию при изменении состояния объекта. И в этом случае, как я писал выше, возврат объекта другого класса — тоже нетривиальная задача, если нужно соблюсти принцип глясящий, что код не должен знать о всех возможных реализациях интерфейса, но только сам интерфейс.
Но всё же статья — очень эмоционально и посредством достаточно спорных обобщений выражает этот смысл. Впрочем, сама завязавшаяся вокруг статьи дискуссия того стоила. По крайней мере для себя я нашёл много интересных и полезных, как мне кажется, идей и замечаний.
Возможно Вы выбрали неудачный пример со стулом, но мне кажется, что неверен всё-таки сам изначальный посыл, что свойство не имеет никакого отношения к методам. На этом фоне интересно отметить, что в русском языке состояния передаются глаголами — стоит, лежит, падает. То, что мы используем как прилагательные — большой, белый — является отдельными значениями свойств, а сами свойства задаются через «методы» быть (в русском языке опускаемый глагол в настоящем времени, вследствие чего неочевидный), стать. Был белым, стал серым. Причём вполне закономерно, что стал серым в результате внешнего воздействия — кто-то сделал серым. У обоих объектов методы: и у активного, и у пассивного, что в нашем языке выражается через действительный и страдательный залоги. А состояния — результаты выполнения методов.
Такое вот видение абстракции в ООП.
Также хочу заметить, что в действительности нет никаких стульев или ещё каких классов — это не более чем абстрактные названия для конфигураций волновых пакетов в нашем клеточном автомате, который мы называем реальностью.
Поэтому ООП — это всего лишь проекция нашего способа мышления на языки программирования. Независимо от того, поверх процедурной парадигмы (что мы и привыкли ООП называть) или поверх функциональной (что видим в том же Хаскеле, который не называют ООП языком). Так что по итогу — либо и то и другое называть ООП, либо отказываться от самого термина в его нынешнем употреблении.
Но тут ничего не поменяется: термин ООП — давно уже превратился в бренд.
А вот смена логики работы методов stretch..., когда вместо растягивания по одной оси круг начинает растягиваться по двум осям — действительно неправомерна. Для изменения двух осей у круга должен быть отдельный метод вроде stretchRadius. Тогда принцип подстановки Лисков нарушен не будет.
Но скорее всего — какое-то legacy, надо будет поинтересоваться историей развития раньше версии 1.3
Эквивалент перегрузки в других языках.
Тут правда в комментариях сойтись не могут, добро это или зло
Написать в параметрах i, v — очевидней и короче, чем использовать this. Тем более, что this — всегда приходится использовать с оглядкой — в той ли области видимости мы находимся?
Устаревшая с php 5?
Или это что-то новое?