Як орієнтований на об'єкт PHP? [зачинено]

У мене був шанс провести цікаву розмову з колегами. Більшість з них - це сценарій flash дій або розробники Java.

Ми говорили про те, наскільки добре php обробляє OOP. Я сказав, що PHP може обробляти майже всі матеріали OOP, як PHP 5.2 або 5.3. Я помиляюся? Я не намагаюся отримати відповідь "так / ні", але хотів би почути більше думок розробників.

PHP 5.3 насправді має цілком пристойну підтримку OOP.

Проблема з PHP щодо OOP полягає в тому, що OOP дійсно просто прив'язаний до мови, тоді як у таких мовах, як Java та ActionScript це частина основної концепції, хоча я вважаю обидві погані мови OOP через їхню погану семантику об'єктів.

Навіть незважаючи на те, що PHP сьогодні в основному підходить для OOP, проблема полягає в тому, що:

1. переважна більшість баз коду там (бібліотеки, фреймворки, спеціальний код) не записані в PHP 5.3
2. переважна більшість API є процедурними. arrayвсе ще є найважливішим і найбільш використовуваним типом, і це не є об'єктом.
3. переважна більшість програмістів PHP буде просто дотримуватися процедурного стилю в осяжному майбутньому. PHP не рекламує OOP, на відміну, наприклад, від Objective-C: Objective-C має C як повний підмножина і тим самим дозволяє процедурне програмування в одній з найчистіших форм, але він явно сприяє використанню OOP.

PHP не може просто позбутися всіх застарілих речей. Якби PHP 6 був випущений, що викидає більшість із нього, він, ймовірно, не буде використаний. Це перемогло б його призначення.
І PHP не зміг прийняти достатній темп поступового знецінення речей. Таким чином, пройде певний час, поки він не набере необхідної чіткості та послідовності, якою має володіти хороша мова.

Особисто мені дуже не подобається PHP, просто через весь цей багаж, API та все інше.
Однак рамки, такі як Flow3, Symfony, CakePHP і Codeigniter, є надійною основою для OOP та інших потужних парадигм. Завдяки обмеженості ActionScript і Java, за умови достатнього зусилля (шару абстракції поверх недоліків PHP), PHP може бути рівним або навіть переживати їх.

Підводячи підсумок: З об'єктами OOP PHP нічого поганого немає. Тому ви можете сказати, що це не погана мова ОО . Однак з PHP багато особливо неполадок, наприклад, що об'єкти OOP насправді не інтегровані , а просто включені , тому ви можете стверджувати, що це погана мова ОО.

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

З мого (правда, обмеженого) досвіду, діалекти PHP 5.n цього не роблять. Це занадто просто вислизнути з OOP і вписати в себе суто процедурний кодекс. (Зверніть увагу, що я не вважаю, що PHP - це погана мова з цієї причини. Є багато причин, чому я вважаю, що PHP - це погана мова, але підтримка OOP - не одна з них.;))

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

За першим визначенням PHP, здається, знаходиться внизу списку. Люди часто цитують не об’єктні рядки та масиви як доказ цього. На мою думку, це визначення насправді не має значення. Ви завжди можете загорнути його в об'єкт, якщо він вам справді потрібен , але люди ні, тому що ні. Зазвичай єдина різниця, яку він зробить у коді, змінюється function(var)на var.function(). Синтаксис один не змінює щось із не-OOP на OOP.

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

Можливо, деякі мови краще підходять для вивчення об'єктно-орієнтованого програмування, але я думаю, що це буде відрізнятися від розробника. Для мене він не натискав, поки я не прочитав книгу верблюдів Ларрі Уолла про те, як Perl робить (зробив?) OOP. Наявність явного благословення посилань на приналежність до класу насправді призвело до того, що я зрозумів, що насправді є екземпляр об'єкта проти того, що таке клас. Деякі люди віддають перевагу підході Java до всього часу у навчанні. Оскільки OOP є більш архітектурним питанням, то легше вчитися, коли ви знаєте основні змінні, вирази, послідовність, вибір та ітерацію, тому будь-яка мова, яка не сприймає OOP відразу на вас, має перевагу в освіті на мою думку.

Коли моя дружина взяла вступ до уроку програмування з java, вона постійно засмучувалась public static void mainі складала все в клас, чого вона ще не мала для розуміння, але сказала її вчитель лише для того, щоб довіритись, що вона потрібна. Я намагався пояснити це, але дуже важко пояснити тому, хто ледве дізнався про змінні, чому було б корисно не допустити до них інших частин коду та як вирішити, як розділити його. Ви можете стверджувати, що вивчення процедурного програмування спочатку прищеплює шкідливі звички, а як щодо звички копіювати та вставляти код, який ви не розумієте?

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

Я не можу пригадати точну цитату, але це було від того, хто порівнював необроблений PHP з використанням нового тоді Ruby on Rails, і пішов щось подібне: Rails полегшує написання хорошого коду і важко писати поганий код. PHP полегшує написання поганого коду та робить складний текст хорошого коду. Рядок про PHP в значній мірі підсумовує його на OOP; він цілком може бути гарною мовою ОО, але це робить це трохи складніше.

PHP категоризовано

PHP - це лише мова клею, подібно до BASH або Perl. Це добре, але не добре ні в чому іншому, залишати окремо серйозну роботу. Мова не розроблена. Він просто розвивається шляхом злому різного коду разом на випадковий спосіб (код-і-виправлення).

Складені мови

На відміну від PHP, Java - це компільована мова, яка була правильно розроблена. Існують JSR, що визначають мову, багато корпоративних рамок і концепцій, таких як EJB, JMS, ESB, Spring, Struts, Hibernate та інші.

Корпоративне програмне забезпечення

Що стосується корпоративних систем, Java EE - це рішення, яке відповідає цілі (Enterprise Edition), тоді як PHP використовується в компаніях, які намагаються знизити витрати, наймаючи дешеву робочу силу з меншою кваліфікацією.

Докладено значних зусиль для перетягування PHP в сегмент Enterprise, використовуючи різні рамки. Найбільше - Zend Framework 2 . Принциповою проблемою тут є не об'єктно-орієнтована PHP, але це відсутність дизайну, відсутність сильної типізації, нестандартні рішення стандартних проблем (вид хак для всього) та повна відсутність будь-якої встановленої архітектури.

Дизайн програмного забезпечення (обговорюється архітектура)

З PHP тягар архітектурного програмного забезпечення все ще повністю покладається на розробників, які роблять дуже погану роботу, тобто часто не мають архітектури взагалі, просто випадковим чином кодують і виправляють. Безпека та транзакції відсутні, тому розробники потребують вподобання. У Java одне рішення - це примітка EJB. Також врахуйте той факт, що в PHP нічого не відбувається, якщо ви упустите вилучення винятків або робите різні помилки. Це до часу виконання. З Java ви отримаєте попередження та помилки безпосередньо під час проектування. Це називається стійкістю, але з PHP ви можете продовжувати лише мріяти.

Багатопотоковість

PHP не підтримує багатопотоковість. Код - це завжди один потік. Це перешкоджає його роботі для нетривіальних проблем при більшому навантаженні. З Java EE багатопотокова редакція повністю підтримується, наприклад, через інтерфейс Runnable.

Підтримка та стандарти

Також врахуйте стандарти розгортання, веб-сервіси та інші стандарти. Якщо в Java є великі компанії, такі як Oracle, IBM, RedHat, Apache та багато інших, PHP має лише Zend.

Висновок

На закінчення, PHP - дуже погана об'єктно-орієнтована мова. Строго кажучи, він навіть не об'єктно-орієнтований, а гібридний, що погано від версій> 5, оскільки OOP змішується з процедурним програмуванням. Я б тільки рекомендував PHP як клей, як BASH, але для серйозної роботи я використовував би Java EE.

Споріднені думки

Основна угода з останнім Zend Framework 2 полягає в тому, що він намагається бути схожим на Java EE, але повністю не вдається доставити принаймні віддалений порівняльний набір доступних пакетів, функцій, інструментів, автоматизації, перевірки помилок, архітектури, дизайну та все.

На мій досвід, використовувати PHP для складних проектів дорожче, ніж для Java.

Існують також чутки, наприклад, що PHP означає «Досить жахливе програмування» . Я можу це підтвердити.

Наскільки добре обробляє мову OOP? Я б швидше запитав, наскільки добре я можу написати програму OO способом. Я можу просунути ніс за позицію "все, що повинно бути класом", яку займає Java, роблячи все статичним статичним .
PHP підтримує OOP; це не змушує мене писати лише в рамках OO. Наскільки добре вона справляється, залежить від того, наскільки я добре розумію і пишу програму об'єктно орієнтованим способом.

PHP підтримує риси! (починаючи з 5.4) . Будь-яка мова, яка вміє впорядковувати горизонтальне повторне використання, є достатньо хорошою мовою ОО.

Ну, ми повинні думати, що робить мову більш OO і які причини, що зробили її такою.

JavaScript - це реалізація ECMAScript, яка мала працювати в середовищі браузера як інтерпретована мова . Те, що, як вважають, інтерпретована мова, дуже сильно вплинуло на її синтаксичну / поведінкову конструкцію.

Наприклад, він не слідує за OOP. Але крім того, існує багато фактів, таких як, наприклад, OO-програміст може виявити частину своєї поведінки, як функція підйому дуже заплутаною.

Знову ж таки, є багато речей з такими мовами OO, як C ++, Java, C #, щоб зробити компілятор таким ефективним, як сильний набір тексту . Однак, оскільки JS працює в інтерпретованому середовищі, вона не дотримується сильного введення тексту, натомість мова є невільно введеною .

Крім перелічених вище поведінкових відмінностей, існує багато синтаксичних відмінностей, наприклад, JS має об'єктне літеральне позначення, що може дуже заплутати програмістів C #. Однак у C # також є синтаксис, що знаходиться у прямому значенні, навіть незважаючи на те, що він є компільованою мовою, і такий синтаксис використовується рідко, оскільки це не традиційно стиль коду OO.

Тепер є ще один момент, який диктує, чи добре мова OO: чи вона розвинулася з C ++. Оскільки Java, C # еволюціонують із C ++ і дотримуються подібної поведінки та синтаксису, велика спільнота сприймає таку поведінку та синтаксис як єдину річ OO , і вважає, що будь-яка мова, яка не гальмує подібних подібностей, просто не є ОО.

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

І PHP дуже добре OO. Просто не дивлячись і не відчуваючи, що Java, C ++, C # не робить її поганою мовою OO. Ну я навчився C ++, потім Java, а потім C #.

Отже, до цього моєї голови було дуже добре ОО. Тоді я дізнався JS з дуже хорошої книги "Wrox Pro", і це мене просто перекрило. Мені просто сподобалося поведінка та синтаксична виразність JS. Тоді я усвідомлюю, що синтаксис буквально схожий на об'єкт був у їхньому C #. І зараз під час навчання PHP я відчуваю, ніби він приносить багато речей з обох світів.

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