Разбор ООП с Delphinum

L!MP, воу воу, я же на работе, откуда у мну время разбираться в этом понятии ) пожалей моих работодателей ))

Delphinum, гг, хорошо. Ну тогда на досуге по смотришь.

Почему в интернете почти весь код ООП это огромные простыни для самых простых действий и функций?

# Crack (17.11.2016 / 00:16)
Почему в интернете почти весь код ООП это огромные простыни для самых простых действий и функций?

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

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

Crack, ну таки исходник нужно увидеть, чтоб стало понятно почему именно так в данном конкретном случае. Вообще Альк верно сказал, либо говнокод, либо есть на то свои причины.

# Delphinum (17.11.2016 / 11:25)
Crack, ну таки исходник нужно увидеть, чтоб стало понятно почему именно так в данном конкретном случае.

+100 Именно.
интересно видеть сам код (который вызвал негодование), чтоб составить свое мнение.

Crack, код в классе это ещё не ООП

Хоть и "рвет шаблон", но тем не менее, согласен с данным утверждением.
Чтоб не быть голословным, приведу простой для понятия пример на практике нашего грядущего JohnCMS-7
===
Как все помнят, у нас были системные настройки, которые хранились в таблице cms_settings.
Потом база дегралась ядром и системные настройки были доступны глобально. в виде переменной-массива $set

В новой версии мы избавились от этой таблицы (-1 в к-ве запросов к БД) и перенесли настройки в файл, сами настройки доступны через контейнер.
Более того, эти настройки доступны как объект, в виде реализации (путем наследования) возможностей ArrayObject.
Для чего? А вот щас объясню, тут и кроется главный ништяк

Любители кошерных блокнотов сразу могут дальше не читать, информация только для почитателей IDE.

Глянем сюды.

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

Вроде бы в классе ничего и нет, нифига не реализуется и при беглом рассмотрении его (данный класс) можно было бы смело похерить.
Но если глянуть практическое применение, тут уже выявляются явные преимущества!
К примеру: если глянем сюды, то видно, что мы запрашиваем объект системного конфига (это единственный напряг, где нужно дернуть объект).
А далее одни удобства.
- Есть ЧЕТКАЯ привязка (переменные привязаны к конкретному объекту), что делает элементарным последующий рефакторинг.
- ОГРОМНОЕ удобство в том, что в IDE действует автоподстановка и вам в большинстве случаев не придется лезть в мануалы. чтоб изучать API, автоподстановка все подскажет.
- Если ВНЕЗАПНО Вам захочется ухнать, ГДЕ используется данная переменная, в IDE просто кликните на контекстном меню "find usages" и будет вам счастье
- ну и разумеется, это ОБЪЕКТ со всеми вытекающими, Вы можете в полной мере его использовать.

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

Delphinum, уважаемый, у тебя отличные мануалы.
Запили для начинающих ООП пользователей мануал, где обычный массив можно представить в виде объекта, наследующего ArrayObject, и использованием каментов PhpDoc и со всеми ништяками из этого вытекающими.
Особо надо упомянуть любителей кошерных блокнотов, с последующей агитацией на использование IDE