Witam,

mam w planach napisanie średniej wielkości portalu i mam dylemat.
Umiem dobrze programować w php ale niestety nie obiektowo i teraz jak wy radzicie: nauczyć się obiektoweog programowania i dopiero zabierać się za ten portal czy przy pomocy dotychczasowej wiedzy (na funkcjach) wykonać ten serwis?

Czy będzie jakaś różnica w szybkości i ogólnie?
Proszę o wasze zdanie na ten temat.

Pozdrawiam.

Takie rozmowy to na hydeparku. Przenoszę.

jelsi masz duzo czasu to ucz sie obiektowego (w program obiektowym nie chodzi glownie o wydajnosc, ale o przejrzystosc, elastycznosc i latwosc rozbudowy i zmian aplikacji). jeslie nie masz to korzystaj z tych naredzi i umiejetnosci, ktore znasz najlepiej.

Poznaj podstawy pisania klas i napisz portal obiektowo. W sumie to tylko jego rdzeń... więcej nie ma sensu. Dlaczego? Bo wystarczy to napisać aby się dowiedzieć, iż to że używamy klas wcale nie oznacza pisania obiektowo :] Tak więc zyskasz jakąś wiedzę i praktykę pisząc wersję 1... na tyle jej zyskasz, że możesz już zacząć pisać od nowa ;P

Potem będą wersje druga, trzecia, osiemnasta... może w końcu uzyskasz konsensus pomiędzy przyjaznym dla Ciebie kodem, a poprawnie rozumianym "php obiektowym".

Oczywiście, w tym samym czasie warto by portal już wystartował :] Bo tak to nie wystartuje nigdy. ALe bez praktyki się niczego nei nauczysz. Możesz te dopieszczanie potraktować jako hobby.

wlasnie, dobry pomysl. mysle ze np. dobrze zaczac od zamkniecia funkcji w klasy...

A co myślicie o takim rozwiązaniu: najpierw zrobie tak jak umiem, później ucze sie klas i na koniec wersja 2 na kalsach? Chyba tak będzie najlepiej.

pisz na funkcjach, i w tym samym czasie ucz sie obiektowego, wtedy piszac portal zobaczysz ze moglbys wykorzystac zdobyta wiedze i zrobic z portalu obiekty.

"A co myślicie o takim rozwiązaniu: najpierw zrobie tak jak umiem, później ucze sie klas i na koniec wersja 2 na kalsach? Chyba tak będzie najlepiej."

Ja od 2 lat staram się pisać OOP i nie zawsze wyjdzie dobrze (przykład: mój framework ma już 3 wersje a pisze go rok) a ty mi mówisz, że drugą wersje napiszesz na klasach i będzie dobrze

Jak już powiedziałem... OOP to zupełnie inna filozofia pisania od tej strukturalnej. Nie wystarczy wszystkie zamknąć w class { } aby pisać OOP. To na prawde wymaga przestawienia swojego myslenia na inne tory. Wchodza tutaj tez wzorce, zasady odpowiedzialnosci itp. Dowiesz się tego z książęk.

Najlepiej jest znaleść sobie projekt o wygurowanych założeniach, ale nie taki który potem chcesz sprzedać albo coś - bo zapewniam cię, że nigdy go nie skończysz I zrobić z niego pole bitewne (via mój framework) tak więc piszesz cały czas cos do niego, poprawiasz, piszesz, poprawiasz - nie działa - więc piszesz, poprawiasz - jest nie ładne - więc piszesz poprawiasz... i tak mijają ci kolejne lata a doświadczenia przybywa :]

tak tak, i jak juz uznasz ze jestes w tym dobry to php bedzie przestarzale hehe beda juz inne jezyki;)

Programowanie obiektowe to nie jest domeną php. Obiekty były długo wcześniej i będą długo później.
BTW @Vengeance grubo przesadza. Nauka OOP nie trwa latami.

racja, masz racje, myslec obiektowo mozna sie nauczyc i przyda sie to w innych jezykach.

a pamietacie wywiad z tworca obiektowego, c, c++ ?

"BTW @Vengeance grubo przesadza. Nauka OOP nie trwa latami."
U mnie bez wątpienia trwała dłużej niż rok :]

Zanim człowiek wbił do łba poprzez praktyke najpotrzebniejsze wzorce, zanim przy projektowaniu systemu od razu rozdzielał elementy na odpowiednią ilość klas o odpowiedniej odpowiedzialności... troche to trwa zanim sobie uświadomisz, że klasa News nie powinna być odpowiedzialna jednocześnie za obsługę kategorii... i że nie powinna dziedziczyć bo klasie Request

W trakcie nauki ciekawe krzaki powstają. Owszem, prosty skrypt OOP można napisać po miesiącu.

Dzięki wielkie, gdyby nie Wy, to pewnie zabierałbym sie za nauke klas, a to trwałoby dłuuuugo i serwis by chyba nigdy nie powstał A tak zrobie to po swojemu i z biegiem czasu będe się uczył obiektów i mam nadzieje że powstanie 2 wersja serwisu na obiektach, albo coś innego:) Jeszcze raz dzieki, a teraz zabieram sie za projketowanie skryptu:)

A właśnie czy ktoś mógłby polecić jakiś opensourcowy skrypt (średnio rozbudowany) napisany obiektowo ?

Pozdrawiam

pierwsze co mi przyszlo do glowy to Seagull (framework+CMS wlasciwie)

"A właśnie czy ktoś mógłby polecić jakiś opensourcowy skrypt (średnio rozbudowany) napisany obiektowo ?"

Robiliśmy na forum kiedyś php battle czy jakoś tak :]
Większość nadsyłanych prac była właśnie pisana obiektowo - choćby edycja z shoutboxem do napisania.

Fajną rzeczą są także frameworki. W sumie nie ma w nich wiele skomplikowanych operacji a jedynie opisany poprzez zbiór klas schemat działania :]

Co do Seagull to dla mnie jest on straszny :]

Obecnie wychodzę z założenia, że branie się za pisanie portalu, czy jakiegokolwiek bardziej rozbudowanego skryptu bez wykorzystania programowania obiektowego, a jedynie programując strukturalnie i nie korzystając z żadnych systemów szablonów i ogólnie przyjętych idei, to samobójstwo.
Potem wychodzi z tego taki stwór, którego nie sposób ogarnąć, rozbudować i modyfikować.
Odnosząc się do wypowiedzi przedmówców: owszem można poznać podstawy OOP dość szybko, ale żeby to wszystko poprawnie zrozumieć i posiąść umiejętność pisania obiektowego w pełnym tego słowa znaczeniu tj. nie tworzyć klas jedynie jako koszyki na funkcje, a tworzyć np. relacje między metodami, odpowiednie metody zawierać w odpowiednich klasach (posiadać porządek w kodzie i całym skrypcie) itd. , trzeba trochę treningu .

Ciekawy i prosty system oparty na klasach?

hmm. Mi podobał się kod ADoDB. Jest nie za trudny, dobrze udokumentowany, i ciekawie pokazuje ideę OOP.
Choć tak naprawdę ideę programowania zorientowanego obiektowo pojąłem chyba podczas prac z http://pof.sourceforge.net/ , który, choć ma pewne błędy założeniowe, pozwolił mi zrozumieć, dlaczego jest to tak przydatne.
Swoją drogą - bardzo przydatny system

A jak już ktoś chce czegoś ciekawszego, nowoczesnego i bardzo przydatnego - warto zapoznać sie z eZ components Bardzo dobry materiał do nauki, niestety, dla tych bardziej zaawansowanych...

ezComponents to, jak już DeyV wspomniał kawałek dobrego kodu.
Ale zamiast AdoDB polecilbym zajrzeć do kodu Creole'a. To jest kawałek dobrej lektury.