Процедурний код проти коду OOP

Я закінчив проект на PHP з 13000+ рядків у процедурному стилі [тому, що мені це дуже добре знайоме, хоча я знаю OOP], і проект працює ідеально.

Але чи варто перетворити його на OOP? [ тому що світ зайнятий OOP ]

Мій код не потребує жодної функції OOP [інкапсуляція, наслідування в основному ...]!

То що мені робити?

І яку допомогу я отримаю, якщо перетворять її на OOP?

Мій код не потребує жодної функції OOP

Ви відповіли на власне запитання - якщо в такому випадку вам не потрібен OOP, а ваш проект працює, не перетворюйте його.

Однак слід поглянути на використання OOP для наступного проекту - але тільки якщо це доречно.

У процедурному програмуванні немає нічого поганого - доки він використовується у відповідному місці.

Ні, і не тільки тому, що вам не потрібен OOP.

Якщо ваша програма вже закінчена і працює задовільно, то більше 90% часу це витрачає час, щоб переписати готовий код з будь-якої причини.

OOP не все потужний. Є багато місць, де OOP не слід використовувати, тому не використовуйте його лише тому, що OOP - це тенденція.

Моє загальне перейняття парадигм (і чому жодна з трьох основних парадигм не є правильним або неправильним способом програмування):

Процедурне програмування добре, коли у вас є проблема, яка є простою на високому рівні (хоча вона може бути складною на низькому рівні) і хочете написати відповідний простий лінійний код. Писати та розуміти, можливо, простіше, ніж OO, та функціональним, якщо проблема не потребує сильної розв’язки де-небудь. Приклади: Числовий код, більшість невеликих скриптів, більшість малих підпроблем, як тільки ви розбивали речі за допомогою OO або функціоналу.

Об'єктно-орієнтований код хороший тоді, коли вам потрібно сильно усунути проблеми, оскільки у вас може бути більше ніж одна реалізація деяких проблем. Приклад: Більшість програмного забезпечення для великих підприємств. Ви можете, наприклад, захотіти сильно відокремити бізнес-логіку від логіки презентації, тому що, ймовірно, потрібно буде самостійно змінюватись.

Програмування в функціональному стилі добре, коли потрібен сильний відрив механізму від політики. Приємна модель - функція механізму, яка приймає функцію політики. (Я дізнався про це, переглянувши модуль std.algorithm мови програмування D.) Відведення стану , що змінюється, на межі між кодом політики та механізму, як правило, робить API простішим. Якщо стан, що змінюється, використовується приватно в будь-якому, це детальна інформація про реалізацію. Іншою силою функціонального програмування є паралельність із зрозумілих причин.

Код ніколи не потребує "OOP". Це програмісти, наскільки вони здатні думати в різних режимах, які передбачають, що та чи інша проблема "потребує" $ PARADIGM або найкраще вирішується таким чином.

Часто трапляється так, що програмісти, які знають лише одну парадигму, думають, що їх парадигма - найбільша. Один розмір підходить усім, і всі ми повинні спати в ліжку Прокруста, якщо те чи інше зараз модно.

Ви повинні конвертувати свій проект в OOP лише тоді, коли є чіткі вказівки на потребу OOP. Можливі сценарії, в яких це може статися, є (серед інших):

• розширення масштабів проекту
• додавання в команду більше розробників

і навіть у цих сценаріях конвертувати ваш проект в OOP все ще може не потрібно.

Обидва можуть бути хорошими, обидва можуть бути поганими. Але переоблаштовувати одне на вигляд іншого ніколи не є хорошою ідеєю.

Якщо ви подумаєте, чому OO винайдено, ви побачите, що OOP взагалі не потрібен , але іноді це значно полегшує ваше життя.

Ще в часи кодування C дуже велика програма може стати досить безладним і важко продовжувати працювати. Тому вони винайшли способи розбиття їх на модульні шматки. OOP використовує такий підхід і робить його ще більш модульним, додаючи дані з тими фрагментами програмної логіки, щоб вони ще більше відокремилися від решти коду.

Це дозволяє писати більші та більші програми, впевнено, що ви змінили свого величезного слона завдання на сто завдань розміром з мишами. Додатковий бонус полягає в тому, що ви можете взяти деякі з цих «мишей» і використовувати їх повторно в інших програмах!

Звичайно, реальний світ не зовсім такий, і повторне використання об'єктів ніколи не впадає у спосіб, який він задумав, але це не означає, що це марна парадигма.

Марно - це надмірна залежність від будь-якого стилю кодування. Той, хто робить ОО з тисячею крихітних, нікчемних класів, насправді не робить це правильно - вони роблять кошти з обслуговування для себе (або когось іншого). Кожен, хто пише процедурну заявку, яка має лише 3 функції, також ускладнює життя. Найкращий спосіб - це середні середні об'єкти великих розмірів (іноді їх називають компонентами, куди ми подумали, що ми збираємось один раз), які можуть забезпечити достатню кількість автономного коду та даних, які, швидше за все, будуть використані набагато більше. відокремлено від решти програми.

Моя порада наступного разу: спробуйте написати свій звичайний процедурний код, але створіть єдиний об’єкт вашої основної структури даних. Подивіться, як вам здається, що працювати з ним простіше, ніж передавати дані навколо від функції до функції.

Мій код не потребує жодної функції OOP [інкапсуляція, наслідування в основному ...]!

Як ви знаєте, що?

Чи потрібно підтримувати цей проект? Чи заплановані якісь нові функції? Будуть інші люди, які будуть розвиватися з вами? Ви повторили себе? Чи важко зрозуміти код?

Якщо відповідь "так", то, можливо, ви повинні почати думати про створення скелета ООП та йти цим шляхом.