Просмотр поста

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