[PHP] Proceduralny czy obiektowy? Opcje

[Neymar11]

Witam!
Nie wiem dlaczego, ale sie zastaniawiam.
Nigdy nie wiedzialem, ze istnieje cos takiego jak obiektowe
programowania w PHP (wstyd)...
Dzisiaj podpatrzylem na php.net za mysqli::__construct, bo kiedy
zaktualizowalem PHP do nowszej wersji wyskoczylo mi:
mysql_connect is deprecated use mysqli or pdo instead it czy cos takiego (IMG:style_emoticons/default/tongue.gif)
Wiec popatrzalem za mysqli_connect
Powiedziano mi, ze to jest alias on ::__construct, wiec poszelem na ::__construct
No i co tam zobaczylem?

Object oriented style

[PHP] pobierz, plaintext 
mysqli cos tam fajnego
[PHP] pobierz, plaintext 

Procedural style

[PHP] pobierz, plaintext 
mysqli cos tam fajnego
[PHP] pobierz, plaintext 

No i sie zaciekawilem, ale bardzo przestraszylem, jak ja
ogarne ten obiektowy mysqli... Wiec stwierdzilem, ze nie bede
aktualizowal PHP (IMG:style_emoticons/default/tongue.gif)

Joke...

Musze aktualizowac, bo hostingi juz nigdzie nie beda miec pewnie PHP5.x.x

PYTANIE:

Czy warto zostac przy proceduralnym PHP czy juz kuc obiektowy?
Bo to co zobaczylem na mysqli::__construct to az mi ciarki przeszly ;_;

Prosze o szczerosc, iz bardzo zzylem sie z prostym proceduralnym PHP i nie
mam zamiaru (przynajmniej teraz) przechodzic na obiektywny.

Jaka byla wasza reakcja, kiedy przechodziliscie na obiektowy?
Czy moze od razu zaczynaliscie od obiektywnego?

Z gory dziekuje za odpowiedzi...
Cheers ^^

PS.
Jezeli zly dzial, to bardzo przepraszam i prosze o przeniesienie, gdyz
nie wiedzialem, gdzie i jak ten temat umiescic / otagowac...

[pmir13]

Właśnie taki bajzel jest najlepszym powodem, żeby przejść na obiektówkę i zacząć się uczyć wzorców projektowych. Przy prostych skryptach możliwych do zrobienia i ogarnięcia przez jednego programistę różnica może nie jest tak bardzo widoczna, ale już przy pracy w jakimś zespole przy większym projekcie korzyści z obiektówki są ogromne.

Mając bałagan w strukturalnym kodzie można dojść do pewnej granicy, przy której czas potrzebny na dodanie nowych funkcjonalności czy wprowadzenie zmian zacznie rosnąć wykładniczo. Im ktoś jest lepszy tym dalej ma tą granicę, ale każdy kiedyś ją osiąga. Zaczynają pojawiać się proste błędy, znalezienie których jest coraz trudniejsze, spada motywacja, w końcu projekt nawet jeśli się uda go skończyć jest zbugowanym potworkiem, którego refaktoryzacją nikt inny potem nie chce się nawet zająć.

Inżynieria oprogramowania poszła mocno do przodu w ostatniej dekadzie, istnieją frameworki, które wprawdzie wymagają poświęcenia trochę czasu na naukę, ale po przekroczeniu progu oświecenia bardzo ułatwiają szybkie pisanie wysokiej jakości kodu. Testy jednostkowe upewniają, że można korzystać z gotowych części kodu nie martwiąc się o jego poprawność i nie trzeba od nowa wymyślać koła, a można się skupić na tym co nowe i unikalne dla projektu. Systemy kontroli wersji jak git pozwalają pracować równolegle wielu programistom, umożliwiają eksperymenty i pozwalają w każdej chwili wrócić do dowolnego wcześniej zapisanego stanu w pełni działającego kodu.

Jeśli chodzi o przestarzałe api mysql_, to sam fakt, że jego funkcje nie są napisane obiektowo nie jest tak istotny, jak to, że to api zatrzymało się w rozwoju na mysql w wersji 4.1. Praktycznie żadne nowości z wersji 5+ nie są obsługiwane, w szczególności nie ma prepared statements, które bardzo ułatwiają dbanie o bezpieczeństwo w przypadku gdy przetwarzamy takie zapytania na które użytkownik ma jakiś wpływ. Problemem jest także to, że w sieci jest mnóstwo przestarzałych poradników, napisanych ładnych parę lat temu, często z wysoką pozycją w google i ludzie niepotrzebnie od tego zaczynają naukę.

Jeśli ktoś chce się bawić programowaniem hobbystycznie, na własne potrzeby, dłubiąc sobie jakąś tam swoją stronkę, to może zostać przy proceduralnym php. Jeśli jednak ktoś myśli o pracy zarobkowej, to w tej chwili nie ma wielkiego wyboru, a za kilka lat nie będzie go miał wcale. Po prostu musi zająć się obiektówką, wzorcami projektowymi, poznać przynajmniej jeden popularny framework, założyć sobie repo na githubie, dorwać jakieś porządne ide do php i próbować się na tym wszystkim uczyć.

[Martin-ZG]

Właśnie taki bajzel jest najlepszym powodem, żeby przejść na obiektówkę i zacząć się uczyć wzorców projektowych. Przy prostych skryptach możliwych do zrobienia i ogarnięcia przez jednego programistę różnica może nie jest tak bardzo widoczna, ale już przy pracy w jakimś zespole przy większym projekcie korzyści z obiektówki są ogromne.

Mając bałagan w strukturalnym kodzie można dojść do pewnej granicy, przy której czas potrzebny na dodanie nowych funkcjonalności czy wprowadzenie zmian zacznie rosnąć wykładniczo. Im ktoś jest lepszy tym dalej ma tą granicę, ale każdy kiedyś ją osiąga. Zaczynają pojawiać się proste błędy, znalezienie których jest coraz trudniejsze, spada motywacja, w końcu projekt nawet jeśli się uda go skończyć jest zbugowanym potworkiem, którego refaktoryzacją nikt inny potem nie chce się nawet zająć.

Inżynieria oprogramowania poszła mocno do przodu w ostatniej dekadzie, istnieją frameworki, które wprawdzie wymagają poświęcenia trochę czasu na naukę, ale po przekroczeniu progu oświecenia bardzo ułatwiają szybkie pisanie wysokiej jakości kodu. Testy jednostkowe upewniają, że można korzystać z gotowych części kodu nie martwiąc się o jego poprawność i nie trzeba od nowa wymyślać koła, a można się skupić na tym co nowe i unikalne dla projektu. Systemy kontroli wersji jak git pozwalają pracować równolegle wielu programistom, umożliwiają eksperymenty i pozwalają w każdej chwili wrócić do dowolnego wcześniej zapisanego stanu w pełni działającego kodu.

Jeśli chodzi o przestarzałe api mysql_, to sam fakt, że jego funkcje nie są napisane obiektowo nie jest tak istotny, jak to, że to api zatrzymało się w rozwoju na mysql w wersji 4.1. Praktycznie żadne nowości z wersji 5+ nie są obsługiwane, w szczególności nie ma prepared statements, które bardzo ułatwiają dbanie o bezpieczeństwo w przypadku gdy przetwarzamy takie zapytania na które użytkownik ma jakiś wpływ. Problemem jest także to, że w sieci jest mnóstwo przestarzałych poradników, napisanych ładnych parę lat temu, często z wysoką pozycją w google i ludzie niepotrzebnie od tego zaczynają naukę.

Jeśli ktoś chce się bawić programowaniem hobbystycznie, na własne potrzeby, dłubiąc sobie jakąś tam swoją stronkę, to może zostać przy proceduralnym php. Jeśli jednak ktoś myśli o pracy zarobkowej, to w tej chwili nie ma wielkiego wyboru, a za kilka lat nie będzie go miał wcale. Po prostu musi zająć się obiektówką, wzorcami projektowymi, poznać przynajmniej jeden popularny framework, założyć sobie repo na githubie, dorwać jakieś porządne ide do php i próbować się na tym wszystkim uczyć.

Podpisuje się rękami i nogami. Tylko "obiektówka". Na początku wygląda to strasznie, ale to pozory. A ostatecznie organizacja jest o niebo lepsza, wszystko ma swoje miejsce, a nie jest wrzucone do jednego gara, gdzie drobna zmiana np. wielkości zdjęć robi się półgodzinnym przeczesywaniem kodu. Co do IDE ja osobiście polecam codelobster (IMG:style_emoticons/default/smile.gif) .