Mam uruchomić aplikację webową, którą napisałem bez użycia funkcji Object Oriented PHP.Obiekt PHP zorientowany czy nie?
Naprawdę nie wiem, czy warto wracać i przepisywać części, które skończyłem. Czy PHP zorientowane obiektowo jest warte przepisania całości lub części przyzwoitej działającej aplikacji?
Biorąc pod uwagę, że masz niekompletną aplikację, powiedziałbym, że przerobienie jej w aplikację opartą na obiektach będzie prawdopodobnie pomocne.
Należy wziąć pod uwagę spodziewany rozmiar aplikacji końcowej. Poniżej pewnej złożoności obiekt może być przesadzony, z wyjątkiem doświadczeń związanych z uczeniem się.
Zacząłem unikać obiektów takich jak dżuma, ponieważ moje wstępne wprowadzenie do nich na zajęciach uniwersyteckich było okropne. Niedawno musiałem pracować nad projektem, który został zaimplementowany w obiektach php. dokonanie wymaganych zmian było znacznie łatwiejsze niż w przypadku innych projektów. Odtąd często pracowałem w modelu obiektowym i uważam, że jest on bardzo przydatny do szybkiego tworzenia i łatwiejszego utrzymania.
Nie powiedziałbym, że to jest krytyczne, ale jeśli zamierzasz pójść o wiele dalej z tą aplikacją, poleciłbym zrobić to teraz, podczas gdy nie jest to tak monumentalne zadanie. Powiedziałbym, że konserwacja dobrze napisanego programu OOP może znacznie przewyższać koszty z góry. Zwłaszcza, gdy weźmiesz pod uwagę, że będziesz w stanie odmienić znaczną część kodu, gdy będziesz postępować.
Techniki obiektowe zorientowane na uczenie się przydadzą się, szczególnie w przypadku programowania w innych językach w przyszłości.
Ponieważ dopiero co uruchomiłeś aplikację, możesz przepisać i ulepszyć części, które napisałeś. To zależy od Twojego terminu.
Typowa odpowiedź: "To zależy."
Mam tendencję do pisania strony wyświetlania jako od początku do końca, < html> do </html> strony z skryptami. Ale rzeczy, które dzieją się na tej stronie, były obiektami. Trochę jak ASP biednego człowieka. Podczas gdy ty można mieć wyjście OOP-base, myślę, że to zbyt uciążliwe dla zadania tak żmudnego jak przesypywanie danych do przeglądarki.
Zasady biznesowe i dostęp do danych były więc zgodne z regułami OOP. Prezentacja była skryptem.
Jeśli masz reguły biznesowe, które są nie OOP, poważnie rozważę napisanie ich jako obiektów pod dwoma warunkami: (1) jest "Czy masz czas/wysiłek/pieniądze, aby to zrobić?" i (2) "Czy masz dobre PHP IDE, które ułatwi ci życie?" Jeśli to działa, a zmiana oznacza pisanie w Notepad ++, to nazwałbym to zrobione. :-)
Po prostu nie zgadzam się z consensus ... W większości przypadków nie powiedziałbym "nie". W każdym razie nie jako ćwiczenie akademickie dotyczące kodu handlowego. Jeśli działa, nie zapisuj go ponownie. Jeśli musisz przejść do zmiany/dodawania bitów, wtedy refactor w kierunku praktyk OO (istnieje wiele postów na SO o refaktoryzacji, gdy zmieniasz kod w każdym razie, a nie tylko ze względu na to).
W praktyce, jeśli nie zrobiłeś dużo OOP, to zacznij od małej i poczuj się.
Po zapoznaniu się z podstawami, bardzo przydatny jest dobry podręcznik dla początkujących do Wzorców projektu (I like the Head First book). Większość książek PHP nauczyłaby Cię OOP dość słabo. Uczą cię o dziedziczeniu, ale zazwyczaj nie uczą o luźnym sprzężeniu i faworyzowaniu kompozycji nad dziedziczeniem.Książka z wzorami projektowymi daje lepszy wgląd w to.
PHP wciąż ma reputację "nie robienia" prawa OO. Nie sądzę, aby było to sprawiedliwe, ale jest odbiciem tego, że tak łatwo jest ludziom zacząć bez naprawdę grokowania OOP. Wychodzę na kończynę i mówię, że większość (czasami tak nieznacznie - nazywają to 51%) programistów PHP nie czuje się komfortowo z OOP. Myślę, że można zrobić dobre OO w PHP i jeśli już czujesz się komfortowo z tym językiem, to świetny sposób na rozwijanie swoich umiejętności.
EDIT:
Wystarczy dodać kilka stopek ...
Powiedziałbym spróbować i iść OO po prostu dlatego, że to, czego nie mogą być ponownie wykorzystane znacznie łatwiejsze niż proceduralne jeśli zrobione w prawo
Powiem również, że OO jest dużo bardziej zorganizowany niż proceduralnie. Gdy jesteś w małej skali, łatwo jest pozbyć się niechlujnego kodu OO lub nie. Ale kiedy dojdziesz do większych projektów, twoje procedury muszą być dużo bardziej zorganizowane i przemyślane. Gdzie, podobnie jak w przypadku większych projektów, OO zmusza cię do większej organizacji, dzięki czemu wszystko jest łatwiejsze.
Nie, myślę, że jeśli aplikacja działa tak, jak powinna, nie trzeba jej przepisywać. PHP wcale nie jest w ogóle tematem OOP. Próbują ciężko, ale czasami myślę, że nawet programiści PHP naprawdę nie rozumieją sensu OOP. Jeśli chcesz poznać OOP (co jest z pewnością dobrym pomysłem) spróbuj prawdziwego języka OOP, takiego jak Smalltalk, aby poznać podstawowe pojęcia. Java jest również dobra 2 poznaj podstawowe, choć nie jest to w pełni OOP, a także
Istnieją dwie możliwości: twoja aplikacja jest jednorazowa, która właśnie musi działać teraz i nigdy nie zostanie dotknięta, zaadaptowana, rozszerzona lub zmodyfikowana, lub inna Twoja aplikacja jest początkiem czegoś, nad czym będziesz pracować i używać przez długi czas.
Jeśli to pierwsze, nie łam się doskonale użyteczny kod. Masz lepsze rzeczy do zrobienia z czasem.
Jeśli to drugie, trzeba pamiętać o ważnym fakcie dotyczącym PHP, który jest następujący: źle napisane PHP to koszmar do utrzymania. Nie tak źle jak źle napisane Perl - bo co to jest? - ale na tyle złe, że wcześniej czy później poczujesz silną potrzebę kradzieży wehikułu czasu, wrócisz do momentu, w którym napisałeś kod, który teraz zachowujesz, i wbijasz sobie w oczodół za pomocą icepicka.
Jeśli masz zamiar zachować ten kod z biegiem czasu, poświęć trochę czasu, aby zrobić to dobrze. Oznacza to: jakiś system szablonów, brak tagów PHP osadzonych w HTML, oddzielne pliki dla oddzielnej funkcjonalności i klasy klasy klasy!
Twoje oczodoły będą Ci wdzięczne.
Chciałbym powtórzyć inne odpowiedzi tutaj. Zależy to od rozmiaru aplikacji i tego, ile chcesz się nauczyć na temat OOP.Byłbym jednak ostrożny przy uczeniu się OOP przy użyciu PHP.
Co do ilości PHP to obiektowo zorientowany ... PHP4 zawierało trochę elementów OOP, PHP5 jest lepsze, ale nie jest upieczone w tym języku. PHP działa w obie strony i osobiście lubię to, co możesz wybrać.
W moim umyśle, mamy phper może thorouly wyrzucić koncepcję obiektu (instancji klasy), musimy tylko Array i tryb Klasa:
Wszystkie tablice w początkowym wsparciu trybu dowolnej funkcji array, jak to metoda:
<?php
$array1->array_flip(this);
?>
Zastosowanie ->mode() aby potwierdzić minimalny zestaw danych, a następnie przełączyć klasę mode:
<?php
$array1->mode('class1', $success);
?>
Każda klasa tryb nie ma ->construct() w tym, ale ma ->validate() do sprawdzania minimalnego zestawu danych.
Tablica w trybie nadal mógł korzystać z funkcji tablicy jako metody, ale po użyciu któregoś z nich tablica zostanie przełączony z powrotem do podstawowego trybu tablicy, i musimy użyć ->mode('class1', $success); do trybu powrócić.
Radykalna myśl jest programowaniem zorientowanym na dane, potrzebujemy oddzielnych danych (tablica) i aktywności (metoda klasy).
Moglibyśmy zmodyfikować silnik PHP, aby pozbyć się części OO (zorientowanych obiektowo) i obsługiwać Mode Class, moglibyśmy nazwać to MyPHP.
Na przykład: $array_man1 można ustawić w dwóch trybach: cls_normal_man i cls_crazy_man:
<?php
$array_man1->mode('cls_normal_man')->normal_method1()->mode('cls_crazy_man')->crazy_method1();
?>
Jestem rzeczywiście próbuje myśleć o sposobach promowania lepszego kodu PHP, ale to takie trudne zadanie. . . –