Ніхто не привів жодного скільки-небудь вагомого аргументу на користь ООП на PHP. Все впирається «друже, ех, спробуй і зрозумієш, як це круто»
Якщо ми створюємо GUI-додаток, що працює поки користувач його не зупинить, то там ООП дійсно доцільний, як мінімум в процесі програмування інтерфейсу. Але у випадку з PHP програма працює частки секунди (поки обробляє запит) і той же інтерфейс програмувати не потрібно. Завдання програми на PHP: бути зрозумілою, бути швидкою. І обидва ці випадки не про ООП.
Щоб бути зрозумілою, програмою потрібна проста дружня логіка (це найважливіший рівень абстракції, про який забувають), код без дублів і документація. Щоб бути швидкою їй як мінімум не потрібен зайвий синтаксис.
Аналізуючи той же Laravel я бачу пару хороших речей, які логічніше реалізувати у функціях і купу коду заради коду.
Але ніщо нам не заважає написати полиморфную за логікою функцію q ():
Ця ж функція може приймати SQL-запит або більш складну над-SQL конструкцію, але при цьому більш зрозумілу, ніж ланцюг методів. Хтось може заперечити, що функція буде прив'язана до одного виду бази даних, але тим я нагадаю, що в залежності від типу використовуваної бази ніщо нам не заважає завантажувати потрібний файл з відповідною реалізацією функції, наприклад, mysql.db.php postgresql. db.php
Якщо логіка процедурного коду збалансована, якщо немає дублів коду, якщо є документація, то процедурний код буде краще будь-якого ООП коду за двома критеріями: доступність для розуміння, швидкість роботи. З огляду на, що ООП-код теж вимагає балансування і документації, переваги процедурного стають абсолютними.
А ніхто і не призведе інших аргументів. Їх же немає.
Все що можна реалізувати на ООП можна реалізувати і без нього. Десь ООП зручно. Але частіше немає. Це цілком логічно, так як така доля будь-якої парадигми, технології або інструменту. Навіть молоток зручний тільки для забивання цвяхів, а для закручування шурупів, гвинтів, гайок і штроблення стін уже немає. Це логічно.
Проблема ООП тільки в тому, що його противники намагаються його уникати, а його прихильники тулят його всюди де знайдуть можливим.
Олександр Маджугін.> Можу напевно знайти для вас свої проекти на аудіокасетах. Влаштує?
Так! А є такі. ) Жартую звичайно ж.
> Проблема ООП тільки в тому, що його противники ЗАВЖДИ намагаються його уникати, а його прихильники тулят його ВЕЗДЕ де знайдуть можливим.
Ось така думка мені більше подобається.
> Так! А є такі. ) Жартую звичайно ж.
Угу. Десь повинна валятися реалізація Sokoban для ZX-Spectrum. Правда там тільки два перших рівня картинки яких я знайшов в журналі. А як генерувати свої тоді не придумав.
Олександр Маджугін. Я не стверджую, що процедурне програмування панацея. У відповіді я привів випадки, коли краще використовувати ООП як підхід. Зокрема, якщо реалізується користувальницький додаток (з GUI та ін) Навіть розробляючи фронт-енд на яваскрипт має сенс спиратися на ООПшние можливості цього скриптового мови.
У випадку ж з PHP, або навіть ширше сказати, в разі обробки запитів скриптовою інтерпретується мовою на стороні сервера, фундаментальних аргументів використовувати ПП більше, ніж ООП. Навіть якщо поглянути на Java, і то в ньому використання ООП виправдовується в тому числі і тим, що саме веб-додаток, працює в пам'яті постійно, будучи скомпільований.
До речі кажучи, процедурне програмування легше сприймається споживачами, велика частина яких це розробники з досвідом нижче середнього, або зовсім верстальники. Їм легше буде зрозуміти процедурний код, ніж ООПшний, який рясніє своїми синтаксичними правилами і частіше висмоктаними з пальця поняттями.
Олександр Маджугін. Ви ж розумієте, що конкретно у вашому випадку це проблема не ООП, правда? Цей підхід, як і будь-який інший, в невмілих руках створить лише проблеми. Що для правильного ефективного використання потрібні роки практики, а можливо і десятки років. Я теж бачив поганий код, і я його навіть писав. Але я бачив і відмінний код. Я вивчаю ООП і сучасні методики програмування більше трьох років і в даний момент можу використовувати лише малу частину його можливостей. Щоб використовувати ООП на повну потужність мені потрібно ще не менше трьох років, я так думаю. Але той потенціал і можливості, які я виявив при вивченні мене дуже вразили.
Я працюю приблизно також як ви - свій фреймворк, все налагоджено і т.п. Кілька років б'юся в ООП, намагаюся зрозуміти, де б застосувати. Там, де застосував, різко зростала складність.
Єдине, де поки ООП для мене видався логічний, зрозумілий і обов'язковий - командна розробка або розробка модуля для готового чужого проекту. В цьому випадку я просто поставляю свій клас або набір класів в своєму просторі імен, які вирішують бізнес завдання, можливо надаючи API.
Правильно навчитеся ставити питання. Щодо веб це питання має звучати так: В який момент пора відмовитися від використання ООП?
Для розуміння цього складного моменту спробуйте запив кілька сайтів на ООП фреймворками. Можна на декількох, а можна на одному хорошому. Не має значення. У якийсь момент ви зловите цю тонку грань.
> Якщо ви не пишіть в ООП стилі - ви лох.
Це вже застаріло, зараз в моді відмова від ООП! Подивіться на go - процедурне програмування + інтерфейси.
Подивіться на Scala - функціональні підходи в Java екосистемі (сюди ж Clojure і Kotlin).
У фронтенді суцільна функціональщіна: ClojureScript, Elm, Purescript. Той же модний нині React + Redux.
Так що сміливо забивайте на ООП і почніть писати на Clojure + ClojureScript!
Керівник напрямку розробки
Особисто у мене повне розуміння навіщо потрібно ООП прийшло лише коли я прочитав книгу "Досконалий код".
Прочитайте її, це мастхев книга для будь-якого програміста пише на ООП і (раптом) без. Там навіть є такий розділ: "Розумні причина використання класів" де все детально розжовується. З прикладами.
Якщо закріпіть її книгою Мета Зандрста - то розуміння буде ще глибше.