Разбор ООП с Delphinum

Что скажите по поводу этого конспекта http://rukeba.com/by-the-way/e ... ects/
и этих видео от Егора
https://www.youtube.com/watch? ... =1188
https://www.youtube.com/watch? ... JWZEY

Jahak, по всем главам проходиться лень, вот несколько сообращений:
* Не использовать -er - нууу хз, классы с именами Controller уже давненько стали стандартном в вебе. Да и как еще назвать класс, который есть контроллер?
* Конструкторы не должны содержать выполняющий код - и это правильно
* Делайте классы как можно мельче - логично, но я не понял, что значит "Инкаплируйте максимум 4 объекта"? куда инкапсулировать, в класс? в класс инкапсулируются не объекты, а логика и/или структура, объекты это уже частные случаи класса. Тут либо автора недопоняли, либо перевод плохой
* Методы-* именуйте - я бы не заморачивался на такого рода рекомендация. Просто нужно придерживаться следующего правила - читая имя метода, должно быть понятно "зачем" он и "что" (но не "как") делает
* Делайте объекты не изменяемыми - это очень спорно. Нельзя всю систему построить на неизменяемых объектах. Они конечно очень удобны, но нужна четкая грань, между неизменяемыми и объектами с состоянием
* Пишите тесты вместо документации - а еще лучше вместе
* Не используйте моки, используйте фейки - ага, я бы хотел взглянуть на разраба, который всегда пишет фейки ))) для не знающих в unit-тестах объясню - чтоб написать фейк, нужно заново написать класс, но с сокращенной логикой
* Максимум 5 публичных методов в классе - новичкам полезный совет конечно, но только новичкам ) тут нужно не принимать его за догму, так как много методов в классе это только симптом, и не всегда тревожный
* Не используйте статические методы - тут по ситуации
* Не используйте utility классы, хелперы - опять таки по ситуации, иногда без них придется городить огород
* Функциональное программирование - оно не есть альтернатива ООП
* Избегайте проверки и приведения типов - reflection это не инструмент программиста, это возможность получить доступ при необходимости
* Никогда не возвращайте NULL - в PHP этот пункт не имеет смысла

Delphinum, Ну а что на счет использования интерфейсов, констант, синглтонов и геттеров и сеттеров?

Посмотри еще видео, там он лично объясняет почему например не стоит использовать статические методы

# Jahak (20.01.2017 / 14:52)
Delphinum, Ну а что на счет использования интерфейсов, констант, синглтонов и геттеров и сеттеров?

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

Я знаю почему может быть опасно использовать статичные методы, важно чтоб и вы знали )

Вот его блог http://www.yegor256.com/ думаю стоит почитать

# Delphinum (20.01.2017 / 14:56)
геттеры и сеттеры вещь нужная, главное не превращать объекты в хранилища данных

Ну геттеры и сеттеры это же просто глупое хранилище данных и во втором видео про "ORM — это обидно" он рассказывает чем это плохо технически

Jahak, ну предположим есть у тебя класс Organization в котором есть свойство contactEmployee (контактное лицо организации), ссылающееся на объект класса Employee. Для формирования страницы организации тебе нужно вывести ее контактное лицо:

<div>
  Контакты: <?= $organization->getContactEmployee()->getPhone() ?>
</div>

Тут геттер вполне оправдан. А вот если создается класс, в котором кроме геттеров и сеттеров ничего нет, и эти методы создаются для всех свойств класса, то что то тут не то. Это уже не ООП (а точнее не DDD, ибо именно DDD определяет правила построения модели), а старый добрый RowGateway

Ладно, а что другие об этом могут сказать?

# Delphinum (20.01.2017 / 14:56)
интерфейсам быть
константы порой полезны
синглтон стал антипатерном, и не случайно
геттеры и сеттеры вещь нужная, главное не превращать объекты в хранилища данных

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

AlkatraZ, это холиварная тема, но мир веба движется в сторону интерфейсов. То есть сначала интерфейс, который описывает что умеет класс, а затем уже его реализация (или несколько полиморфных реализаций).

Польза этого подхода такая же, как у PSR - твой код зависит от семантики, а не реализации.