Видимо просто зачесалось:

От действий различных сил на голову я защищён хорошим слоем лучшей фольги.(нет авторитета который был давил паттернами)
Необходимость в использовании ООП увидел когда почитал код своего коллеги. А потом ещё раз взглянул на свой. Даже без комментариев его код выглядит более структурировано и понятно. Пока ещё не поздно(самое начало приложения) хочу использовать ООП, чтобы в дальнейшем кто-то из коллег мог взять реализацию части функционала на себе или подменить меня на время отпуска ну и т.п. Короче для улучшения сопровождаемости кода.
Ну и может всётаки на меня действует ООП мода)))
За статью - Спасибо.

PHPLamer
структуировать код можно и без ООП. ООП это умение соответствующим образом мыслить. Иначе у тебя получится тот же говнокод только еще более запутаный.
ООп нужно применять когда ты начинаешь понимать - вот в этом месте мне нужен объект. А не просто лепить обьекты где попало.

код может быть структурован и понятен без использования ООП и паттернов. Что все заладили ООП и ООП. Я например два года коджу и сам толком не знаю ООП. И разделяю я теоретиков и практиков. А практика имеет свойство быть совсем другой чем теория. Поетому если пишите для себя то конечно да - пишите в ООП с использованием тонны патеррнов. Через месяц згляните на то что написали и перепишите заново. Потом еще раз - потому как небывает ничего идеального. И если Вы замечаете ошыбки в своем коде - значит вы учитесь. И вместо того чтобы спрашиваь про какую-то вакуумную область возьмите и попробуйте. А атм и практика придет, и понимание и т.д.

П.С. все сказаное ИМХО и может не соотвествовать мнению других.

к сожалению чтобы начать понимать надо сначала "просто лепить объекты"
esterio соответствует

Я с ООП не дружу, о чем писал страницы 3-4 назад.
Вот почитал литературу, появилась мысль, прошу опытных людей сказать, правильная она или нет.
Мысль такова - ООП это дальнейшие шаги к абстракции; если бы программирование не двигалось в сторону абстракции, мы бы до сих пор программировали единицами и ноликами.

То есть, функция, к примеру, round(х,у) - это тот же класс. Мы знаем как функция принимает входящие значения (х - округляемое число, у - степень округления) и знаем как она выдает результат. Что происходит внутри (в ядре функции) - это скрыто. Так же с классом.

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

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

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

Нет ничего более абстрактного чем единицы и нолики. Найдите перфоркарту и расскажите о чем вам ее дырки поведали.

Для тех кто начинает изучать. Не все так сложно когда понимаешь и все очень сложно когда не понимаешь. Это общее правило изучения предмета? Это общее правило изучения любого предмета. Нет другого пути как создать в голове структуру ответственную за понимание этого предмета - понятие. Нейронно именно так все и происходит. Чтобы понять как устроен объект или явление - надо организовать определенным образом связи в мозгах. Пока эти связи не установлены - вы не понимаете. Устанавливаются - начинаете понимать, установились более-менее - поняли. Затем только наращивание мощности. Мощность потребляет ресурсы, требует приложения силы. Поэтому дело не в сложности - а в трудности. Хотите что-то понять - не бойтесь трудностей.

В программировании нет разницы из чего растут объекты. Это не реализация, а принцип. В процедуре вы имеете дело с набором типов данных. Целое, строка, с точкой, дата и тп. В объекте - со структурой. Структура описывается в классе. Затем нетрудно воткнуть в эту структуру ссылки на точки вызова функций и выложив по известным смещениям параметры - вот вам и методы. Которые в пределах выделенной памяти под подведомственную им структуру могут ей оперировать. Таким образом у процедуры нет интерфейса - у объекта он есть. Процедура может взаимодействовать с другими процедурами повинуясь коду процедуры main (грубо говоря, внепроцедурному коду). Обхект взаимодействует с другими объектами согласно плану - классу - через свой интерфейс.

Интерфейс это станция пересадки. Например я сейчас использую веб-интерфейс доступа к объекту БД этого форума. Поедая колбасу вы используете как интерфейс системы питания - рот и желудок.

Короче, если не понятно - смотрите первый абзац. Нельзя ничего понять не понимая.
(Добавление)
Много метафор для ООП, типа вот чертеж, вот здание. Это значит класс и объект. Прикольно, тогда инъекция объекта будет означать проникновение через окно, а статический объект - жизнь на чертеже. Типа на ночь дом собирают, на день разбирают.

Так вот, я еще одну придумал. Процедуры плавают в питательном бульоне пока их не соединят в объекты - в молекулы способные реплицироваться. Репликация обусловлена наличием интерфейса, того самого. Объект может взять и сам себя скопировать. А функция - не может. У нее нет плана постройки самой себя, у нее нет ДНК. У объекта - есть такой план - это класс. Поэтому ООП это жизнь, а ПП - не жизнь. Что не умаляет, конечно.

Кстати, жизнь с точки зрения ООП - абсолютно абстрактна. Способна появляться в любых достаточных для репликации условиях. Напишите такой класс, попробуйте.
(Добавление)
UPD, у процедуры есть интерфейс, но примерно такого метафорического порядка как если вас подключить не к колбасе с хлебом, а к аппарату закачивающему в вены все необходимые питательные вещества.

Спустя пару годиков программирования с помощью ООП на PHP, могу это образно сравнить следующим образом.

Действующие "лица" в процедурном стиле программирования:

1. главнокомандующий - это сам программист
   
2. генерал - это PHP
   
3. оружие - это функции
   
4. библиотеки функций - это наемные солдаты
   
5. боеприпасы - это данные и переменные
   
6. поле боя - страницы скрипта
   

Действующие "лица" в ООП стиле программирования:

1. главнокомандующий - это сам программист
   
2. генерал - это PHP
   
3. карты поля боя - это абстрактные классы и интерфейсы
   
4. структуры спецвойск (пихота, артилерия, десант...) - это классы готовые для реализации
   
5. особые войска - связисты - это области видимости (public, protected, private)
   
6. солдаты спецвойськ - это объекты классов
   
7. войска союзников - это библиотеки классов
   
8. оружие - это методы классов
   
9. боеприпасы - это данные и переменные
   
10. поле боя - страницы скрипта
    

лучше бы ты за эти пару лет освоил какую профессию не связанную с программированием

В армию сходил

И что тебе, как специалисту высокого класса, показалось в моем сравнении не правильным?

сравнение настолько бессмысленное что определение правильного и неправильного также теряет всякий смысл

Ото ты такой специалист...