Jak obiektowo zorientowany jest PHP? [Zamknięte]

Miałem okazję odbyć interesującą rozmowę z moimi współpracownikami. Większość z nich to skrypty flash lub programiści Java.

Rozmawialiśmy o tym, jak dobrze PHP obsługuje OOP. Powiedziałem, że PHP może obsłużyć prawie wszystkie rzeczy związane z OOP począwszy od PHP 5.2 lub 5.3. Czy się mylę? Nie próbuję uzyskać odpowiedzi tak / nie, ale chciałbym usłyszeć więcej opinii od programistów.

PHP 5.3 ma całkiem przyzwoite wsparcie dla OOP.

Problem z PHP w odniesieniu do OOP polega na tym, że OOP było naprawdę przykręcone do języka, podczas gdy w językach takich jak Java i ActionScript jest to część podstawowej koncepcji, chociaż uważam oba złe języki OOP ze względu na ich słabą semantykę obiektową.

Chociaż PHP jest obecnie w dużej mierze odpowiednie dla OOP, problem polega na tym, że:

1. zdecydowana większość kodu bazowego (biblioteki, frameworki, kod niestandardowy) nie jest napisana w PHP 5.3
2. zdecydowana większość API ma charakter proceduralny. arrayjest nadal najważniejszym i najczęściej używanym typem i nie jest przedmiotem.
3. zdecydowana większość programistów PHP będzie trzymać się stylu proceduralnego w dającej się przewidzieć przyszłości. PHP nie promuje OOP, w przeciwieństwie do na przykład Objective-C: Objective-C ma C jako pełny podzbiór, a tym samym umożliwia programowanie proceduralne w jednej z najczystszych postaci, ale wyraźnie preferuje użycie OOP.

PHP nie może po prostu pozbyć się wszystkich starszych elementów. Gdyby wydano PHP 6, który wyrzuca większość, prawdopodobnie nie zostałby użyty. Pokonałby swój cel.
A PHP nie osiągnął wystarczającego tempa stopniowej deprecjacji. Zajmie to trochę czasu, zanim osiągnie niezbędną jasność i spójność, jaką powinien mieć dobry język.

Osobiście bardzo nie lubię PHP, po prostu z powodu tego całego bagażu, interfejsu API i wszystkiego.
Jednak frameworki takie jak Flow3, Symfony, CakePHP i Codeigniter zapewniają solidną podstawę dla OOP i innych potężnych paradygmatów. Z powodu ograniczeń ActionScript i Java, przy wystarczającym wysiłku (warstwa abstrakcji na wadach PHP), PHP może je równać, a nawet wyprzedzić.

Podsumowując: Nie ma nic szczególnie złego w urządzeniach OOP PHP. Dlatego możesz powiedzieć, że to nie jest zły język OO . Jednak jest wiele rzeczy szczególnie źle z PHP, takich jak narzędzia OOP, które tak naprawdę nie są zintegrowane , ale raczej tylko włączone , dlatego możesz argumentować, że jest to zły język OO.

Przekonasz się, że „ obsłużyć ” to nie to samo co „ obsługuje ”. Chodzi mi o to, że nawet C „ poradzi sobie ” z OOP, jeśli poprawnie ustrukturyzujesz swój kod. Pytanie brzmi, czy język wykracza poza zwykłe umożliwienie OOP jego zachęcania, czyniąc OOP najbardziej naturalnym sposobem programowania.

Z mojego (co prawda ograniczonego) doświadczenia, dialekty PHP 5.n nie robią tego. Zbyt łatwo jest wymknąć się z OOP i przejść do kodu czysto proceduralnego. (Zauważ, że nie uważam, że PHP jest złym językiem z tego powodu. Istnieje wiele powodów, dla których uważam, że PHP jest złym językiem, ale obsługa OOP nie jest jednym z nich;))

Tak naprawdę istnieją dwie definicje orientacji obiektowej języka: jak obiektowa jest własna wbudowana składnia i biblioteki standardowe oraz jaki ma wpływ na programistów piszących w tym celu.

Według pierwszej definicji PHP wydaje się być na dole listy. Ludzie często wskazują na ciągi i tablice niebędące obiektami jako dowód na to. Moim zdaniem ta definicja tak naprawdę nie ma znaczenia. Zawsze możesz owinąć go w obiekt, jeśli naprawdę go potrzebujesz , ale ludzie nie, ponieważ nie. Zazwyczaj jedyną różnicą będzie to zrobić do kodu zmienia function(var)się var.function(). Sama składnia nie zmienia niczego z non-OOP na OOP.

Jeśli chodzi o drugą definicję, ludziom udaje się pisać słabo zorientowany obiektowo kod, nawet w językach, które silnie wymuszają takie konstrukcje, a ludzie, którzy piszą dobry zorientowany kod obiektowy, prawie wcale nie odczuwają wpływu języka, z wyjątkiem tego, że denerwują go dziwactwa składniowe. Innymi słowy, z mojego doświadczenia wynika, że ​​nie ma złych języków zorientowanych obiektowo, tylko źle zorientowanych obiektowo programistów . PHP jest pod tym względem tak dobry, jak każdy inny język.

Być może niektóre języki lepiej nadają się do nauki programowania obiektowego, ale myślę, że programista może się różnić. Dla mnie nie kliknęło, dopóki nie przeczytałem książki wielbłąda Larry'ego Walla o tym, jak Perl robi (zrobił?) OOP. Konieczność bezpośredniego błogosławienia referencji jako należących do klasy naprawdę sprawiła, że ​​uświadomiłem sobie, czym tak naprawdę jest instancja obiektu w porównaniu z klasą. Niektórzy ludzie preferują podejście Java do tworzenia wszystkich obiektów przez cały czas. Ponieważ OOP jest bardziej kwestią architektoniczną, łatwiej jest się uczyć po znajomości podstawowych zmiennych, wyrażeń, sekwencji, selekcji i iteracji, więc moim zdaniem każdy język, który nie narzuca OOP od ciebie, ma przewagę edukacyjną.

Kiedy moja żona wprowadziła się na zajęcia z programowania w Javie, ciągle była sfrustrowana public static void maini umieszczała wszystko w klasie, czego nie miała jeszcze do zrozumienia, ale nauczycielka powiedziała jej, że musi tego potrzebować. Próbowałem to wyjaśnić, ale bardzo trudno jest wytłumaczyć komuś, kto ledwo dowiedział się o zmiennych, dlaczego warto uniemożliwić dostęp do nich innym częściom kodu i jak zdecydować, jak je podzielić. Możesz argumentować, że nauka programowania proceduralnego wpaja najpierw złe nawyki, ale co z nawykiem kopiowania i wklejania kodu, którego nie rozumiesz?

PHP nie jest złe dla programowania obiektowego. Jednak natura PHP zachęca do szybkich hacków i poprawek w porównaniu z odpowiednim programowaniem obiektowym, a wiele książek i samouczków całkowicie ignoruje koncepcje OOP. Może dobrze wspierać koncepcje OOP, ale to na programistach spoczywa obowiązek ich zastosowania. W PHP można zrobić wszystko, co można zrobić w „prawdziwym” języku OOP, takim jak Java lub C #, ale języki te mają lepsze wymuszanie technik OOP niż PHP, które można zastosować w stylu proceduralnym, jeśli się zdecyduje.

Nie pamiętam dokładnego cytatu, ale to było od kogoś, kto porównał surowe PHP z użyciem nowego wówczas Ruby on Rails, i poszedł mniej więcej tak: Railsy ułatwiają pisanie dobrego kodu, a pisanie złego kodu trudnym. PHP ułatwia pisanie złego kodu i utrudnia pisanie dobrego kodu. Wiersz o PHP prawie podsumowuje to na OOP; doskonale potrafi być dobrym językiem OO, ale sprawia, że ​​jest to trochę trudniejsze.

PHP skategoryzowane

PHP jest tylko językiem kleju, podobnie jak BASH lub Perl. Jest w tym dobra, ale nie jest dobra w niczym innym, pomijając poważną pracę. Język nie jest zaprojektowany. Jest to ewoluowane przez hakowanie różnych kodów razem w przypadkowy sposób (kod i poprawka).

Języki skompilowane

W przeciwieństwie do PHP, Java jest językiem skompilowanym, który został odpowiednio zaprojektowany. Istnieją JSR definiujące język, wiele struktur i koncepcji klasy korporacyjnej, takich jak EJB, JMS, ESB, Spring, Struts, Hibernacja i inne.

Oprogramowanie firmowe

Pod względem systemów korporacyjnych Java EE jest rozwiązaniem, które pasuje do tego celu (wersja Enterprise), podczas gdy PHP jest używane w firmach, które starają się obniżyć koszty poprzez zatrudnienie taniej siły roboczej o niższych kwalifikacjach.

Poczyniono znaczne wysiłki, aby przeciągnąć PHP do segmentu Enterprise przy użyciu różnych platform. W szczególności Zend Framework 2 . Podstawowym problemem tutaj nie jest zorientowanie obiektowe PHP, ale jest to brak projektu, brak silnego pisania, niestandardowe rozwiązania standardowych problemów (rodzaj włamań do wszystkiego) i całkowity brak jakiejkolwiek przepisanej architektury.

Projektowanie oprogramowania (omówiona architektura)

W przypadku PHP ciężar architektury oprogramowania nadal leży w pełni w rękach programistów, którzy wykonują bardzo słabą robotę, tj. Często nie mają żadnej architektury, tylko losowo kodują i naprawiają. Brakuje bezpieczeństwa i transakcji, dlatego programiści muszą uzyskać odpowiednie wsparcie. W Javie jednym rozwiązaniem jest EJB z adnotacją. Weź również pod uwagę fakt, że w PHP nic się nie dzieje, jeśli pominiesz łapanie wyjątków lub popełnisz różne błędy. To jest do czasu wykonania. Dzięki Javie będziesz otrzymywać ostrzeżenia i błędy bezpośrednio w czasie projektowania. Nazywa się to solidnością, ale dzięki PHP możesz tylko śnić.

Wielowątkowość

PHP nie obsługuje wielowątkowości. Kod jest zawsze pojedynczym wątkiem. Utrudnia to jego działanie w przypadku nietrywialnych problemów przy większym obciążeniu. W Java EE wielowątkowość jest w pełni obsługiwana, na przykład przez interfejs Runnable.

Wsparcie i standardy

Weź również pod uwagę wdrożenie, usługi sieciowe i inne standardy. Podczas gdy w Javie istnieją duże firmy, takie jak Oracle, IBM, RedHat, Apache i wiele innych, PHP ma tylko Zend.

Wniosek

Podsumowując, PHP jest bardzo złym językiem obiektowym. Ściśle mówiąc, nie jest on nawet obiektowy, ale hybrydowy, co jest złe w wersjach> 5, ponieważ OOP jest pomieszane z programowaniem proceduralnym. Poleciłbym PHP tylko jako klej jak BASH, ale do poważnej pracy użyłbym Java EE.

Powiązane myśli

Główną kwestią związaną z najnowszą wersją Zend Framework 2 jest to, że stara się być jak Java EE, ale całkowicie nie zapewnia przynajmniej zdalnie porównywalnego zestawu dostępnych pakietów, funkcji, narzędzi, automatyzacji, kontroli błędów, architektury, projektowania i wszystko.

Z mojego doświadczenia wynika, że ​​używanie PHP do złożonych projektów jest droższe niż w Javie.

Krążą też pogłoski, że PHP oznacza dość okropne programowanie . Mogę to potwierdzić.

Jak dobrze język obsługuje OOP? Wolę zapytać, jak dobrze mogę napisać program w sposób OO. Mogę kciukiem wbić postawę „wszystko, co powinno być klasą”, jaką zajmuje Java, upubliczniając wszystko .
PHP obsługuje OOP; nie zmusza mnie to do pisania tylko w sposób OO. To, jak dobrze sobie z tym poradzi, zależy od tego, jak dobrze rozumiem i piszę program w sposób obiektowy.

PHP obsługuje cechy! (od 5.4) . Każdy język, który natywnie poradzi sobie z ponownym użyciem w poziomie, jest wystarczająco dobrym językiem OO w mojej książce.

Cóż, musimy pomyśleć o tym, co czyni język bardziej OO i jakie są powody, dla których tak się stało.

JavaScript jest implementacją ECMAScript, która miała działać w środowisku przeglądarki jako język interpretowany . Fakt, że uważa się go za język interpretowany, miał bardzo duży wpływ na jego składnię / zachowanie behawioralne.

Na przykład nie jest zgodny z OOP. Ale poza tym istnieje wiele faktów, takich jak OO programmer może uznać niektóre z jego zachowań, takie jak podnoszenie funkcji, za bardzo mylące.

Znów jest wiele rzeczy związanych z językami OO, takimi jak C ++, Java, C #, aby uczynić je kompilatorami wydajnymi jak silne pisanie . Ponieważ jednak JS działa w środowisku zinterpretowanym, nie stosuje silnego pisania, a jest językiem luźno pisanym .

Oprócz powyższych różnic behawioralnych istnieje wiele różnic składniowych, takich jak JS z notacją Object Literal, która może bardzo dezorientować programistów C #. Jednak C # ma również składnię podobną do literału Object, chociaż jest to język kompilowany i taka składnia jest rzadko używana, ponieważ nie jest to tradycyjny styl kodu OO.

Teraz jest jeszcze jedna kwestia, która decyduje o tym, czy język jest dobry OO: czy ewoluował z C ++. Ponieważ Java, C # są ewoluowane z C ++ i podążają za podobnym zachowaniem i składnią, duża społeczność postrzega takie zachowanie i składnię jako jedyną rzecz OO i myśli, że każdy język, który nie hamuje takich podobieństw, po prostu nie jest OO.

Nie zapominajmy jednak, że OO jest pojęciem bardzo abstrakcyjnym, nie jest związane z żadnym stylem składni, a nawet z żadną konkretną właściwością zachowania.

A PHP jest bardzo dobrze OO. Po prostu nie patrząc i nie czując się jak Java, C ++, C # nie czyni go słabym językiem OO. Cóż, nauczyłem się C ++, potem Java, a potem C #.

Do tej pory moja głowa była bardzo dobra. Potem nauczyłem się JS z bardzo dobrej książki „Wrox Pro” i to mnie przerosło. Po prostu podobało mi się zachowanie i syntaktyczna odrębność JS. Potem zdaję sobie sprawę, że składnia podobna do literału Object była w ich języku C #. A teraz podczas nauki PHP mam wrażenie, że przynosi wiele rzeczy z obu światów.

Wszystko, co naprawdę musimy zrobić, to nauczyć się składni i subtelności zachowania, jakie ma język podczas implementacji OO. Po ich opanowaniu możemy zacząć myśleć, że jest to lepsza implementacja OO.