Malcom na swoim blogu podzielił się swoimi przemyśleniami na temat obiektowości w webdevelopingu, choć nie tylko. Jako że nie zgadzam się za bardzo, z tym, co napisał - odpisałem mu w komentarzu. Tak się tam rozpisałem, że zyskałem i materiał na wpis na moim blogu :)
Strukturalnie czy obiektowo?
Jakie podejście jest lepsze - strukturalne czy obiektowe? Tym pytaniem chciałbym wywołać dyskusję, w jakich przypadkach lepiej jest stosować jedno, bądź drugie rozwiązanie. Nie można bowiem powiedzieć, że tylko jedno jedyne podejście jest słuszne, a inne całkowicie odpada.
Moim zdaniem, w webdevelopingu rządzi obiektowość. Wymagania co do moich projektów poszerzają się bardzo szybko. Bez obiektowości konserwacja aplikacji jest bardzo ciężka. Przykładem jest tutaj portal geograficzny GeoZone.pl - 3 lata dopisywania kolejnego strukturalnego kodu doprowadziło do kresu możliwości dalszego rozwoju. By dokonać jedną zmianę trzeba odwiedzić kilkanaście różnych miejsc w kodzie. A potem i tak nie działa to do końca tak, jak chcę.
Do realizacji algorytmów oczywiście obiektowość i wzorce projektowe nie bardzo się nam przydadzą. Tutaj rządzi C/C++ ze wględów wydajnościowych. (Oczywiście do organizacji struktur danych wykorzystujemy struktury, czy klasy - jak zwał, tak zwał - jednak nie stosujemy tu dziedziczenia, polimorfizmu, wzorców, itd.) Kto rozwiązywał zadania na SPOJ-u, ten wie o co chodzi ;) A kto nie, temu tłumaczę, iż liczy się każda sekunda wykonywania programu.
Cytaty z MalDevBlog, komentarz Nowakerowy
Oczywiście przewagą ActiveRecorda jest miedzy innymi to, że wystarczy zmienić implementację sterownika bazy i można generować zapytania do dowolnej bazy, bez poprawiania kodu. Ale czy znów tak często zmieniamy bazę danych, szczególnie w nieco mniejszych aplikacjach?
Często może i nie, co nie oznacza, że nie warto stosować warstwy abstrakcji na bazę danych. Za pół roku możesz np. zdecydować, że przenosisz swoje wszystkie projekty ze względów wydajnościowych z MySQL na PostgreSQL - i co wtedy zrobisz? Albo mozolnie zmienisz wszędzie mysql_ na odpowiedniki pg_ albo… olejesz sprawę, bo będzie z tym zbyt dużo roboty.
Inna sprawa, to porozrzucanie po 40 klasach 4 funkcji, i tworzenie 10 obiektów tylko po to, aby zmienić jakąś regule w routingu czy funkcjonalność w innym module. I później przedzierać się przez tony dokumentacji i kodu, aby w efekcie otrzymać zamierzony cel działania ;)
Wg mnie nie masz tutaj racji, ponieważ dokumentację bedziesz musiał tylko raz przejrzeć, aby zrozumieć, o co chodzi. Później już nie będziesz tego odczuwał. Gdy zaś przyjdzie czas na jakąś przeróbkę w routingu, pójdzie ona gładko, podczas gdy w strukturalnym projekcie nie obeszło by się bez skakania po plikach i zmieniania wszystkiego po kolei w wielu miejscach.
Jednorazowe napisanie projektu obiektowo wymaga więcej pracy, aniżeli strukturalnie. Gdy zaś przychodzi czas na przeróbki, zyskujemy dużo czasu w stosunku do podejścia strukturalnego.
Tak myślę, że chyba jednak dokończę tego własnego frameworka. Ileż to różnych projektów wstrzymałem, zawiesiłem, czy porzuciłem na różnych stopniach zaawansowania prac. Głównie z braku czasu i zmian w zapotrzebowaniu i użytkowaniu danego produktu (projektu).
Według mnie to upadło w wyniku strukturalnego projektowania. Zmieniło się zapotrzebowanie i okazało się, że napisany strukturalnie system nie jest już w ogóle przydatny. Przemyślany obiektowy system daje się łatwo wykorzystywać dalej oraz modyfikować, a więc i szansa powodzenia projektu jest większa.
Na koniec zapraszam na blog Malcoma.
7 responses so far ↓
Malcom // maja 29, 2008 at 01:10
Dla scislosci nie poruszalem tematu struct vs. oop, bo akurat sam sobie nie wyobrazam pisac czegokolwiek wiekszego (nawet malego) nie obiektowo czy to w php, czy c++ ;)
Ale mozna zaobserwowac w wielu projektach i kodach napisanych w php podejscie javowe, ktore mi osobiscie nie zbyt przypada do gustu (tak jak sama java), gdzie wszystko jest pakowane w obiekty, gdzie aby zrobic malutka rzecz trzeba utworzyc 40 instancji roznych klas i wzajemnie nimi zaglowac :P
Co do przedostatniego akapitu o upadku projektu, moge powtorzyc po raz kolejny, ze nie stalo sie to z powdu strukturalnego projektowania, bo oczywiscie projekt byl OOP. Nie co zmienily sie moje zamilowania i odejscie od webdeveloperki oraz narzut zbyt wielu obowiazkow i nowych roznorakich projektow.
Nowaker // maja 29, 2008 at 01:22
Oczywiście, Twój wpis nie był na temat strukturalnie vs obiektowo. Mój wpis to tylko lekkie nawiązanie ;)
Co do “Javowskiego” stylu - styl ten mi odpowiada. Wg mnie jest lepszy od tego, co mamy w PHP. Co prawda w Javie pisałem tylko jeden projekt (mała gra) na zaliczenie przedmiotu, jednak trochę się z tym nakodziłem i jakieś doświadczenie w tym mam.
Nawiasem mówiąc Java ma bardzo duży wkład we wzorce projektowe, czy architekturę frameworków. Bez Javy dużo tego co mamy po prostu by nie było.
Marcin Kłeczek // maja 29, 2008 at 08:45
Hm.. nie dajmy się zwariować. Co powinno być obiektowe, to powinno być obiektowe, a co strukturalne - zostawić strukturalne.
Obiektowość ma sens, jeśli są ku temu przesłanki - jeśli jest sensowne dziedziczenie i możliwości łatwej wymiany/żonglowania klasami (dobrym przykładem są operacje na obrazkach, które można zamknąć w 1 funkcji publicznej, a w prywatach dodatkowe wymagane obliczenia/operacje - jest 1 interfejs i za każdym razem wiesz jak z niego skorzystać - operacje dotyczące obrazka mogą być zapisane w bazie i w dowolnym momencie odtworzone/powtórzone). Sensowne (IMO) jest również grupowanie funkcji w klasy, jeśli dotyczą podobnych struktur danych (np. operacje na wybranym typie pliku, bądź “specyficznym stringu”) - dodawanie klasy dla 1 funkcji (”simpleurl” modyfikującej string do znaków wyświetlanych w URLu) - tylko dlatego, że “wszystko ma być obiektem” jest bez sensu.
PHP był i jest językiem przede wszystkim strukturalnym. Obiektowość jest już sensownie rozwinięta, nie zmienia to faktu, że większość funkcji głównych była/jest/będzie strukturalna. Dlatego nie ma sensu całkowite wyparcie się programowania strukturalnego. Jednocześnie warto (ale tylko tam, gdzie to ma sen) używać obiektowości.
Czytanie kodu obiektowego wcale nie jest prostsze niż kodu strukturalnego (i odwrotnie). Podobnie z modyfikacją i zastępowaniem (duże serwisy) - natomiast z dopisywaniem jest już różnica - łatwiej w serwisach obiektowych.
Jeszcze co do “upadku” (geo) - jeśli było napisane niechlujnie, zmieniały się zamysły (inne zupełnie kierunki rozwoju i duuuże przebudowy) to nawet obiektowo napisany serwis stanie się z czasem trudny do modyfikacji/rozwoju (a jak jeszcze do tego dojdzie zmiana developera :D )
Marcin Kłeczek // maja 29, 2008 at 08:46
I usuń tą captchę, bo można ją automagicznie odczytać, więc tylko wydłużasz czas pisania komentarza :)
Nowaker // maja 29, 2008 at 21:43
Co do tego “simpleurl” to również bym tak nie zrobił. Wrzuciłbym tę metodę (statyczną) do klasy-helpera url. (Taki sztuczny namespace z uwagi na to, że PHP nie posiada przestrzeni nazw, czy pakietów - jak kto woli. W frameworku KohanaPHP przyjęto taką konwencję do grupowania prostych funkcji o jednej sferze działania)
To, że PHP jest przede wszystkim strukturalne - widać.
$f = fopen('plik')while (!feof ($f)) ...
$line = fgets ($f)
grrr… Czy by nie było lepsze coś w tę deseń?:
$f = new FileStream ('plik')while (!$f->eof()) ...
$line = $f->getLine()
Obiektowy nie upadnie, jeśli jest napisany obiektowo, a nie korzystając z mechanizmów programowania obiektowego ;) Bo obiektowo się projektuje. Chodzi właśnie o to, aby dokładnie zaplanować, co będzie potrzebne i w jaki sposób osiągnąć późniejszą łatwość konserwacji. Wzorce projektowe odgrywają tutaj bardzo ważną rolę. Pozwolę sobie zamieścić krótki cytat z książki “Wzorce projektowe. Analiza kodu sposobem na ich poznanie”, A.Holub:
A Geo upadło, pisałem je lat 3 temu strukturalnie. Przeróbki były naprawdę znaczne.
Captcha - hmmm, nie widzę, żeby w ogóle była :D A odpaliłem mojego bloga w innej przeglądarce. A może Captcha dezaktywuje się po napisaniu pierwszego zaakceptowanego komentarza? Popatrzę w ustawieniach ;)
Dzięki za komentarz.
Zyx // maja 30, 2008 at 10:24
Sztuka to znaleźć kompromis. Zaletą kodu strukturalnego jest jego prostota i wydajność, której czasem mi trochę brakuje, jak patrzę na współczesne kody. Prawda, że półstrukturalny kod mojego blogu modyfikuje się ciężko, ale za to jest krótki i śmiga, aż miło.
Nowaker // maja 30, 2008 at 23:58
Zyx, w moim przypadku strukturalne GeoZone to ślimak. ab -n 200 -c 10 dla GeoZone.pl daje wynik 44.5 req/s. Zaś strona mol-ksiazkowy.com.pl na frameworku Kohana ma wynik 46 req/s. Tyle że zawartość księgarni dostarczana jest protokołem SOAP! ;)
[Ta księgarnia jest jeszcze "under development", dlatego nie linkuję. Zostało mi jeszcze kilka funkcji i zamawiam szablon.]
Leave a Comment