Дмитро. я напевно погано сформулював свою думку. але я розумів так:
Ось у мене є самописна CMS. Ось у мене є купа функцій, контент з бази збирають (model типу), а ось є купа функцій, контент оформляють для виведення (типу view).
Ось є один варіант кінцевого уявлення, а ось інший. Model один і той же всюди, а view в частково перекриваються.
Я так подумав - ну а чо, чому б не зробити це з ООП? Зібрав усі model під одним дахом - мені стало тупо зручніше їх викликати:
$ X = new SampleModel ();
$ Y = $ x-> prepareAuthorsList ();
$ V = new TemplateXYZ (); (Який успадковується від TemplateBase)
$ W = $ v-> showAuthors ($ y);
зрозуміло, назви абсолютно умовні :)
а не "printAuthorsListFromDBforBootstrapTemplate (мульон параметрів)"
Зібрав. Стало тупо зручніше. При цьому в процесі збору з'ясувалося, що частина "вьюшних" функцій в різних в'юшках нічим не відрізняються - грубо кажучи, і там я сам виводять- *<>
Але напевно це ще не ООП :)
А то в ООП логіка не розмазується по всій програмі. І два десятка локалізованих полів і 60 методів в класі відмінно покращують наочність. У процедурному програмуванні компоненти, природно, не замінюються без танців з бубном.
Бидло-ООП програми переписують з нуля також часто, як і бидло-процедурні програми. Добре написані програми Новомосковскются і редагуються без особливих проблем при використанні будь-якої з парадигм.
В результаті застосування принципів ООП дозволяє економити час і сили розробників. Безграмотне ООП (або ООП через недосвідченість) дозволяє прострелити собі коліно, а Новомосковскющім - голову, 37 раз.
З мінусів ООП - класи як правило універсальні, повинні стабільно працювати при будь-яких валідних параметрах. Частенько це виливається в множинні перевірки на одні і ті ж умови, проблеми при відкритті елементів (іноді їх закривають від балди, але іноді воно дійсно треба), надмірні вимоги (коли для вирішення задачі використовується клас із зайвою функціональністю). Все це може привести ще і до втрати швидкодії.
Загалом, там є про що подумати. І граблів предостатньо.
Я хотів запитати: ви що, студент? Потім подивився: немає, вебіст. Вебістам дійсно ООП потрібно вкрай рідко; якщо не зв'язувався з хитрою підтримкою складних протоколів або зі складними моделями даних - в пам'яті, не в БД - можна писати без ООП і бути успішним вебістом.
Я і сам довгий час не розумів, на що потрібні ці об'єкти. Головне питання: ДЛЯ ЧОГО?
Для того, щоб передати взаємодію купи речей. Де немає взаємодії, там немає ООП, і можна займатися, наприклад, науковими розрахунками, на які мало хто з нас здатний, вищий пілотаж, і взагалі про ООП нічого не знати. Пам'ятаю, як Вассерман - той самий, що колись програміст впровадження нових технологічних процесів - довго-довго згадував, що таке ООП.
Пропоную почати з простого.
1. Об'єктний синтаксис. Було ...
Уже стало гарніше. Та й номер собаки можна випадково передати, наприклад, замість номера зброї; з типом TMonster такий фокус не пройде.
2. Інкапсуляція.
Це ми вже думаємо над тим, щоб виклики функцій не могли привести об'єкт в «неналежне» стан, а все, що може об'єкт зіпсувати, - засунути в private.
3. Абстракція і успадкування. Це вже «складний пілотаж». Чи не вищий - це невід'ємна частина навичок хорошого програміста, та й для 80% завдань це не потрібно, зате в інших 20-і дуже покращує життя. Найпростіший приклад. У якийсь 2D-грі є якийсь TGameObject, у якого віртуальні функції Live і Render. Перша прокручує такт «життя» об'єкта, друга малює його на екрані. TGameObject можна розбити на TPlayer, TProjectile, TEnemy і TBonus, і т.д.
Ах да. Для ООП не потрібен об'єктно-орієнтована мова і об'єктний синтаксис, потрібно об'єктно-орієнтоване мислення. Наприклад, Doom був написаний на Сі, але в дуже-дуже об'єктному стилі.
по простому і на практиці, наприклад
1) вам потрібно підключити платіжку до сайту
а) написати взаємодія з нуля самому (дорого і не рентабельно)
б) взяти готовий клас, якщо потрібно отнаследовать і переписати деякі методи (швидше і надійніше)
2) берете якусь бібліотеку (або навіть CMS), наприклад бібл. IdiORM, код ядра (ядро це основні класи) не міняєте, а успадковуєте в свій клас переписуєте кілька потрібних методів, через 5-10 років код вашого проекту не застаріє, так як ядро можна буде оновлювати не поламати проекту, та й все косяки і уразливості за 10 років для вас устранятся шляхом оновлення бібліотеки або cms
3) ОПП дозволити розробляти швидше, наприклад на основі готових бібліотек і фреймворків вставка запису в таблиць може виглядати так
в функціональному стилі такого не реалізувати
PS на жаль не все що реалізовано на ООП, реалізовано якісно. Є приклади зловживання ООП і навпаки ускладнення розуміння коду, але це не означає, що не варто користуватися ООП підходом.
Самі смакоту від мови С ++ це спадкування і віртуальні функції.
Крім того, закриті члени класу підвищують надійність і оберігають від помилок.
Найжахливіше в програмуванні на мові C це використання глобальних змінних. Не знаєш, де вона може змінитися і занадто складно змінювати поведінку програми. А якщо її зміна змінної зробити в одному місці (в класі), то дуже легко модифікується поведінка класу.
Ну і звичайно ж дуже зручно, коли методи роботи з об'єктом (класом) зберігаються в одному місці.
У PHP ООП потрібен, коли кількох функцій потрібно звертатися до загальних змінним.
Без ООП довелося б писати код виду:
З ООП можна написати:
Без ООП серверна частина web додатки може виглядати так:
А з ООП так (як можна помітити, модулі реалізовали у вигляді класів, які містять тільки 1 метод, тобто клас тут зайвий):
Але якби PHP використовувався для розробки не серверного, а клієнтської програми, де згенерувала візуальна частина зберігалася б в оперативній пам'яті довгий час і призначені для користувача дії змінювали б її, то використання ООП може бути зручним. Але знову ж таки, ООП - це просто спосіб організації коду, в основі якого лежать все ті ж підпрограми (методи) і цей спосіб організації не всім може сподобатися.