Инкапсуляция в объектно-ориентированном PHP - когда она действительно нужна?

Я знаю, что это своего рода вопрос веры, и его задавали много раз раньше, но ответы, которые я нашел, были либо слишком общими, либо неприменимыми к моему варианту использования, либо не удовлетворяли иначе.

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

Теперь, похоже, консенсус в ООП заключается в том, что вам всегда нужно использовать геттеры и сеттеры вместо прямого доступа к атрибутам класса.

Я часто слышал аргумент, что использование геттеров и сеттеров дает возможность расширить эти функции позже, но, на мой взгляд, это идет вразрез с YAGNI и некоторыми другими концепциями, название которых я не могу вспомнить прямо сейчас - что метод должен сделайте именно то, что вы ожидаете от его названия. Если бы я хотел сделать что-то большее, чем просто установить значение, я бы написал новый метод, а не помещал бы его в свой метод установки, поскольку он, согласно определению, должен только устанавливать атрибуты. Так что я мог бы также пропустить сеттер и просто получить доступ к атрибуту напрямую.

Другой - то, что вы можете поместить валидацию в свои сеттеры, что я уже делаю в своем API, который обращается к этим классам. На мой взгляд, вы не должны просто передавать значения, чтобы объект сообщал вам, в порядке ли ваше значение, а вместо этого сначала проверяйте эти значения, прежде чем передавать их объекту.

Я понимаю назначение частных / защищенных атрибутов в «обычных» классах, но когда класс буквально является просто контейнером данных без каких-либо методов, действительно ли это необходимо? Другими словами: есть ли явный недостаток в использовании общедоступных значений, когда методы установки для них (были ли они частными) в любом случае выглядели бы как public function getAttr($attr) { $this->atrr = $attr; }?


person Besasam    schedule 22.02.2018    source источник
comment
Вы единственный, кто поддерживает код? Может ли кто-то другой установить атрибут, который, как ожидается, будет объектом DateTime (например), как строку даты или что-то подобное? Однако в конечном итоге этот вопрос, вероятно, будет закрыт как «Основанный на основном мнении», поскольку единственный возможный точный ответ - это зависит от ...   -  person CD001    schedule 22.02.2018
comment
Объектно-ориентированная инкапсуляция - когда она действительно нужна? - инкапсуляция - одно из фундаментальных свойств объектно-ориентированного кода. Без инкапсуляции нет ООП, кроме процедурного программирования. Когда свойства объекта имеют сеттеры и геттеры, это процедурный код, замаскированный под ООП.   -  person axiac    schedule 22.02.2018
comment
но когда класс буквально представляет собой контейнер данных без каких-либо методов, почему он все еще классы php?   -  person bxN5    schedule 22.02.2018
comment
@ bxN5, потому что я использую ORM, который требует, чтобы в таблицах базы данных были соответствующие классы.   -  person Besasam    schedule 22.02.2018
comment
Класс - это комбинация свойств и поведения. Поскольку у вашего класса нет поведения, а есть только свойства, вы получаете процедурный код, завернутый в класс, переходящий к анемичная модель домена.   -  person emix    schedule 25.02.2018


Ответы (1)


Вам нужна только структура данных, но единственная подходящая конструкция PHP - это класс.

Обычно в объектно-ориентированном анализе, проектировании и программировании класс представляет собой модель предмета или концепции, и он инкапсулирует любые знания и / или поведение предмета или концепции.

Однако в контексте этого вопроса инкапсуляция не требуется, поскольку вам нужна только структура данных.

person RWRkeSBZ    schedule 24.02.2018