OOP w PHP

[burzam]

heh

to nie jestem sam

tez przerzucam sie wlasnie na obiektowke

php5 za jakis czas, na razie przygotowanie sie - klasy, klasy i jeszcze raz klasy

napisze jedna, wykorzystuje ja dalej... no

i tak powstaja juz pierwsze panele administracyjne do zarzadzania trescia

i to jest piekne, bez wysilku, bo z lenistwa

peace

[michal]

jeno to PHP 5 jeszcze mało popularne. jakoś mało hostów ma tą wersję PHP, a więc na razie mało użyteczna.

To nie powinnno być problemem. Trzeba znaleźć taki hosting, który ma obsługę PHP5, a wybór jest dość duży.

Ja narazie tylko eksperymentuje z obiektami na localhoscie. Niestety nie mam czasu na czytanie obszernych książek o programowaniu, ale radzę sobie w taki sposób, że ściagam sobie skrypty open source, albo inne z dostępem do kodu źródłowego, które mnie interesują i zaczynam analizę skryptu i robie próby.

Może to nie jest najlepszy sposób, ale tak właśnie się nauczyłem wszystkiego co jest związane ze stronami, od html począwszy.

[MMP]

wzorce projektowe, zgadza się ?

Ja wzorców nienawidze, chodź są przydatne mam ksiązke z wzorcami, lecz niektóre rozwiązania są wg. mnie kiepskie, przynajmniej w moim systemie. Nie są uniwersalne a czasem miałem przez nie większe problemy, dlatego... tworze własne wzorce do moich projektów

PHP. Zaawansowane projektowanie. Vademecum profesjonalisty

Mam, ale tej ksiązki wybitnie nienawidze i nie potrafie jej czytać. Już prędzej przeczytam całych Krzyżaków niż to. Może dlatego że jest trudna, ale jak dla mnie autor to kretyn( ) Poleca coś co wg. niego nie ma wad, przynajmniej ja sie nie doczytałem żadnej wypiski opcji które on polecał.

ło rany, toto drugie niezła cegłówka,

Cegłówka to 'biblia php' albo 'Tworzenie stron WWW', a ta ksiązka to co najwyżej styropian

jeno to PHP 5 jeszcze mało popularne. jakoś mało hostów ma tą wersję PHP, a więc na razie mało użyteczna.

Nie myśl tak, łatwo znaleźdź serwery obsługujące php 5, a jak piszesz coś dużego dla dużej firmy, to ona będzie miała jakiś serwer dedykowany albo coś tego typu. Więc ja bym nie patrzył na ograniczenia serwerów.

mi daleko do obiektowości :0 to raczej jakies poplatanie z pomieszaniem

I takie coś jest najlepsze, stosowanie tylko OOP to jak dla mnie przekleństwo(przynajmniej w php bo innych języków nie znam), dziesiątki klas które można zastapić jedną klasą. Tak samo jest z MVC....

[nrm]

całe te frameworki, mvc etc. to _dla mnie_ przerost formy nad treścią. mojavi i inne - toz to kobyły tylko po to żeby obsługiwac jeszcze cała reszte

z php5 najbardziej do gustu przypadl mi _autoload fajna sprawa.

[Elf]

całe te frameworki, mvc etc. to _dla mnie_ przerost formy nad treścią. mojavi i inne - toz to kobyły tylko po to żeby obsługiwac jeszcze cała reszte

Taaa. Choc widze, ze to dosc powszechne mniemanie. Byc moze wynika z tego, ze programisci PHP pisza generalnie caly kod sami i to od podstaw. Znaczenie ma tez fakt, ze powstaje niewiele naprawde duzych projektow w PHP.

To pisanie kodu proceduralnego ciagle od nowa jest zamknieta petla. Przy obecnym poziomie skomplikowania aplikacji nie da sie napisac jakiejs wiekszej i uniwersalnej procedury. Chcac wykorzystac ponownie taki kod trzeba poprawic cialo funkcji. Nie mowiac juz o zmianach w innych czesciach kodu, ktore implikuja zmiany w ciele procedury.

Ze juz nie wspomne o szkole projektowania obiektowego, modularyzacji, projektach z wieloma wykonawcami z podzialem kompetencji. W sferze kodowania PHP te pojecia sa rzadko uzywane. Zaczynam rozumiec co mial na mysli moj znajomy - doswiadczony programista Javy mowiac, ze PHP jest dla harcerzy.

[Erbit]

Przy obecnym poziomie skomplikowania aplikacji nie da sie napisac jakiejs wiekszej i uniwersalnej procedury. Chcac wykorzystac ponownie taki kod trzeba poprawic cialo funkcji.

Nie do końca z Tobą się zgodzę... Czasem uzupełniam funkcję - to fakt, ale czynię to tak, aby poprzedni program nadal mógł jej używać...

Nie zgodzę się z Tobą odnośnie 'uniwersalnej procedury'... być może tylko dlatego, że pierwsze starcie z programowaniem miałem 20 lat temu. Zawsze piszę w taki sposób aby później móc napisaną procedurę podłączc gdziekolwiek indziej... ale może wynika to z mojego doświadczenia.

[Elf]

Przy obecnym poziomie skomplikowania aplikacji nie da sie napisac jakiejs wiekszej i uniwersalnej procedury. Chcac wykorzystac ponownie taki kod trzeba poprawic cialo funkcji.

Nie do końca z Tobą się zgodzę... Czasem uzupełniam funkcję - to fakt, ale czynię to tak, aby poprzedni program nadal mógł jej używać...

Nie zgodzę się z Tobą odnośnie 'uniwersalnej procedury'... być może tylko dlatego, że pierwsze starcie z programowaniem miałem 20 lat temu. Zawsze piszę w taki sposób aby później móc napisaną procedurę podłączc gdziekolwiek indziej... ale może wynika to z mojego doświadczenia.

88317[/snapback]

Zgadzam sie. Chyba kazdy stara sie tak pisac. Zauwaz jednak, ze to ty poprawiasz te procedury. Znasz je na wylot i nie sprawia ci to klopotu. Jesli jednak musialbys wspoltworzyc projekt z kilkunastoma innymi osobami, to interfejs takiej procedury bylby koszmarny, bo musialby zawierac wiele zmiennych.

Nie twierdze, ze programowanie strukturalne jest zle. Przeciez obiektowe odziedziczylo po nim bardzo wiele. Tu jest jednak potrzebna zmiana myslenia.

[Erbit]

...Znasz je na wylot i nie sprawia ci to klopotu....

Nie twierdze, ze programowanie strukturalne jest zle. Przeciez obiektowe odziedziczylo po nim bardzo wiele. Tu jest jednak potrzebna zmiana myslenia.

Dokładnie tak jak napisałeś...

[Elf]

Wlasnie. Piszemy tu o przetwarzaniu, jednak obiekty to znacznie wiecej. Obecnie to kwintesencja programowania. Dawniej program okreslano jako algorytm + struktury danych. W obiekcie mamy to zintegrowane! W koncu te dwie scisle powiazane plaszczyzny sa w pelni zespolone i jako obiekt tworza zupelnie nowa wartosc. Nareszcie mamy mechanizm, ktory powoduje ze dane nie sa oderwane od procedur ich przetwarzania.

[Erbit]

...Obecnie to kwintesencja programowania....

Miezupełnie... czasem pisze własne procedury / funkcje gdyż nie odpowiada mi sposób działania obiektu.

...Dawniej program okreslano jako algorytm + struktury danych. W obiekcie mamy to zintegrowane! ...

i czasem te struktury danych są do d.... czyli robie dokładnie to co wyżej napisałem.

...Nareszcie mamy mechanizm, ktory powoduje ze dane nie sa oderwane od procedur ich przetwarzania.

Nie bardzo rozumiem Twą fascynację.. obiekty w programowaniu w rożnych językach dostepne są juz od 95r a moze i wczesniej... Obiekty mają swe zalety ale też mają swe wady.

Generalnie nie przepadam za obiektami... dlaczego ? Dlatego że funcjonują one tak, jak je zaprojektowano i wykonano.. niestety czasem jest to niewystarczające szczególnie wtedy jak tworze specjalistyczne oprogramowanie a nie np komunikator internetowy, do którwego wystarczy wstawić kilka obiektow, potem pare klikniec i jest komunikator...

[Elf]

...Nareszcie mamy mechanizm, ktory powoduje ze dane nie sa oderwane od procedur ich przetwarzania.

Nie bardzo rozumiem Twą fascynację.. obiekty w programowaniu w rożnych językach dostepne są juz od 95r a moze i wczesniej... Obiekty mają swe zalety ale też mają swe wady.

88413[/snapback]

Jest czas zeby zachwycac sie nowa technologia, jest czas by ja poznawac i testowac, apotem nastepuje okres uzywania. I wlasnie w tej ostatniej fazie jestesmy jesli chodzi o programowanie obiektowe.

Na strudiach uczyli mnie, ze przy wdrazaniu nowego rozwiazania wsrod uzytkownikow powstaje opor. Jak sie teraz przekonalem, takze developerzy (potencjalnie bardziej podatni na innowacje) bronia sie przed zmianami. Dobra nauka na przyszlosc

[Elf]

Ciekawy głos w temacie:

https://phppl.ezpublish.no/wortal/artykuly/...kontra_oo_w_php

[wieja]

Ze juz nie wspomne o szkole projektowania obiektowego, modularyzacji, projektach z wieloma wykonawcami z podzialem kompetencji. W sferze kodowania PHP te pojecia sa rzadko uzywane. Zaczynam rozumiec co mial na mysli moj znajomy - doswiadczony programista Javy mowiac, ze PHP jest dla harcerzy.

Ciekaw jestem co takiego ma java czego brakuje php5 w kwestji OOP dla www? php4 faktycznie miało "pseudo obiektowosc", pozatym to oczym piszesz bardziej wiąze sie z tym ze aby w php napisac cos (strukturalnie) trzeba mniej wiedzy i doświadczenia niz w java(obiektow). Osobiscie nieprzepadam za java, dla www wole php a dla apikacji okienkowych C#

Co do urzywania obiektowosci to bezsesu jest pisanie obiektowe bo tak mamy problem i go rozawiazujemy optymalnie - niekoniecznie obiektowo. Osobiście jedanak uważam ze przy systemach intranetowych dla których bardzo istotne jest bezpieczeńswto - lepiej urzyc OOP.

Co do materiałów dla strukturalnych programistów php chcacych cos poczytac o obiektowosci i "fachowym" projektowaniu i kodowaniu aplikacji:

PHP5 zaawansowane programowanie (choc jest tam spiepszona abstrakcja bazy danych)

Co do hostingu z php5 to jest coraz lepiej, a jesli robi sie komercyjny system intarnetowy to niewyobrazam sobie zeby admin serwera niedoinstalował php5 jako cgi jesli go niema.

[Elf]

W php5 to najbardziej mi brakuje cech C++, czyli dziedziczenia z wiecej niz jednej klasy (ten problem niejako rozwiazuja interfejsy) i przeciazania operatorow

Piszemy używam.

[Erbit]

Nie to bym miał coś przeciw książkom.... ale jak dla mnie wieksząść przepastnych książek wydawnictwa Helion (innych Polskich także) zawierajacych niepotrzebne wywody autorów (często są to dość błędne próby napisania błędnych programów, funkcji....) nie nadają się dla mnie...

Wolę manual'a, który nie dość, że zawiera pełen opis funkcji to na dokładkę czasem pojawią się przykłady ich stosowania.

Myśleć wolę sam - częstokroć błędne sugestie autora - nie są mi do niczego potrzebne...