Zastanawiam się czy warto tworzyć małe klasy z kilkoma funkcjami zamiast tworzenia po prostu samych funkcji, jak choćby do wyświetlania komentarzy przy newsach czy artykułach, do generowania menu, do formatowania dat i czasu? Funkcje same w sobie spełniają założoną funkcjonalność jednak w obiekcie były by prostsze w użyciu i dawały większe możliwości manewrowania danymi, choć nie wiem czy takie rozwiązania nie były by wtedy bardziej obciążające dla samego serwera.

Jakieś rady od wprawionych już w boju??

czy warto?To zleży od osoby, stylu pisania itp. Czy powinno się?Tak! Nawet dla klasy która ma tylko jedną metodę , ułatwia to bardzo czytanie kodu, robi go przejrzystym i łatwym do poprawy.

Albo programujesz obiektowo albo proceduralnie.
Z tego co zrozumiałem używasz już klas do innych większych rzeczy, więc używaj klas w całości a nie raz a raz tak.

Używam klas do większych rzeczy jak szablony styli, sesje, autoryzacja uprawnień. Nie wiem tylko jak później sobie poradzić w przekazywaniem tych klas mniejszych do większych, aby nie pogarszać wydajności w dużym stopniu..

Od tego to już są wzorce projektowe. A tych metod jest kilka fajnych, chociażby ostatnio za sprawą symfony 2 popularne staje się dependency injection.

Tak jak napisał @nospor obiektówka to obiektówka, jeżeli masz kilka klas a reszta kodu jest strukturalna, to żadna to obiektówka. Tak jak niektórzy autorzy CMS'ów opisując swoje dzieło że ich cms jest full oop, a w gruncie rzeczy używają tylko kilku klas, z czego większość to pdo + mailer i już tworzą z tego obiektowy cms

Małe klasy z kilkoma metodami warto tworzyć, możesz wtedy tą samą klasę wykorzystać w różny sposób.

Odnośnie wzorców, daleko nie szukając, praktycznie pod nosem: http://php.pl/Wortal/Artykuly/PHP/Architek...emow-w-praktyce

rozumiem, a jeszcze jedno pytanie, jak można wywołać takie działanie??

[PHP] pobierz, plaintext 
$user->setData($data)->save();
[PHP] pobierz, plaintext 

bo gdyby to wyglądało tak:

[PHP] pobierz, plaintext 
$user->setData->save();
[PHP] pobierz, plaintext 

no to wtedy wiadomo że przekazaliśmy sobie klasę setdata do user i wywołujemy save, ale tego pierwszego zapisu nie rozumiem, znaczy nie potrafię sobie wyobrazić jak wygląda struktura klas aby to zadziałało poprawnie a natrafiłem na taki przykład wykonania na jakiejś stronie..

[PHP] pobierz, plaintext 
class Lancuch 
{
 
	public function ala() 
	{
		return $this;
	}
 
	public function ma() 
	{
		return $this;
	}
 
	public function kota() 
	{
		return $this;
	}
 
}
 
$lancuch = new Lancuch();
$lancuch->ala()->ma()->kota();
 
[PHP] pobierz, plaintext 

Po prostu w metodzie zwracasz obiekt klasy.

czyli mówiąc dokładniej jeśli w funkcji ala np pobiorę dane użytkownika z bazy, i wrzucę w zmienną $this->data i zwrócę $this, to byłoby to równoznaczne z takim kodem:

[PHP] pobierz, plaintext 
class class1
{
 
	public function get() 
	{
 
	}
 
 
}
 
class class2
{
        public $class1;
 
	public function __construct($class1) 
	{
		$this->class1 = $class1;
	}
 
	public function set() 
	{
 
	}
 
}
 
$class1 = new class1;
 
$class2 = new class2($class1);
 
$class2->get()->set();
[PHP] pobierz, plaintext 

czy chodzi o coś innego??

Po pierwsze twój kod nawet nie zadziała. Żeby zrobić "ciąg" wykonywanych metod, w każdej z nich musisz zwracać jakiś obiekt, w twoim przypadku tej samej klasy.

W klasie masz metody save oraz setData. W metodzie setData ustawiasz dane i w metodzie zwracasz obiekt, a dalej możesz wykonywać inne operacje.

[PHP] pobierz, plaintext 
class X 
{
 
	private $data = array();
 
	public function setData(array $data) 
	{
		$this->data = $data;
 
		return $this; // Zwracasz obiekt klasy X
	}
 
	public function save() 
	{
		// Zapis danych...
	}
 
}
 
$data = array('foo' => 'bar');
 
$x = new X();
$x->setData($data)->save();
 
[PHP] pobierz, plaintext 

no tak zapomniałem return wsadzić.

czyli w Twoim przykładzie gdyby tego return nie było to można by ten sam efekt otrzymać w ten sposób??

[PHP] pobierz, plaintext 
$data = array('foo' => 'bar');
 
$x = new X();
$x->setData($data);
$x->save();
[PHP] pobierz, plaintext 

jest jakaś znacząca różnica pomiędzy oboma przykładami?? co daje takie zwracanie obiektu??

Dokładnie tak, różnicą w tym przypadku może być wygoda pisania, zaoszczędzać parę linijek kodu

rozumie, w sumie całkiem ciekawe zastosowanie

a jest jakiś darmowy skrypt forum, cms itp napisany w 'całości' obiektowo??

W PHP nie ma niczego napisanego "w całości obiektowo", bo PHP nie jest językiem stricte obiektowym - jest językiem wieloparadygmatowym, a zdecydowana większość jego biblioteki standardowej jest strukturalna, więc siłą rzeczy zawsze znajdują się w nim elementy strukturalne.

dlatego całości jest w cudzysłowu, a jakiś w dużym stopniu pisany obiektowo istnieje??

Szukaj jakichś frameworków, takich jak symfony, zend, yii i tym podobne. Kilka cmsów obiektowych by się znalazło, ale przeważnie są to już napisane aplikacje z użyciem jakichś frameworków, jak chociażby ten cms: http://diem-project.org/ akurat napisanie cms'a kiedy ma się już framework to jest prosta sprawa, tak szczerze mówiąc najważniejsze są podstawy które udostępnia ci dany framework, tworzenie później newsów, artykułów, forum itp to można w niektórych cms'ach wykonać na prawdę szybko, niektóre mają gotowe generatory, lub nawet gotowe pluginy, dzięki czemu napisanie jakiegoś blogaska to może być kwestia godzin.



nic innego jak method chaining: http://www.webnote.pl/method-chaining-w-php.html ciekawe, ale nie wszędzie dobrze jest to stosować, zależy tak na prawdę od tego czego chcesz od obiektu. Jeżeli powiedzmy przekazujesz do obiektu szereg danych, do różnych metod, to wtedy można bawić się w method chaining, ale wszędzie pchać tego raczej nie polecam

a jest jakiś poradnik żeby się w tym całym diem połapać, bo ciężko byłoby coś popróbować robić na ślepo a plików jest tam strasznie dużo..

1. Dokumentacja Symfony / ZF / jQuery.
2. Dokumentacja samego projektu.

Mam jeszcze jedno pytanie. Posiadam klasę odpowiedzialną za szablony z kodem html, deklarowaną na początku kodu do zmiennej. Dotychczas używałem kilku funkcji aby tę klasę wykorzystać i wprowadzać zmienne w szablon, czyli wpisywałem w funkcji global $zmienna_szablonu i działąlo to poprawnie, jednak teraz chciałbym wsadzić klasę szablonu w inną klasę odpowiadającą za przetwarzanie samego widoku oraz generowanie tego co ma się pojawić np lista newsów, artykułów itd, no i nie wiem czy deklarować klasę szablonów na początku i przy deklarowaniu drugiej klasy wprowadzić wcześniej zadeklarowane szablony do tej drugiej klasy czy też zadeklarować w pliku np index.php tą drugą klasę i w środku drugiej deklarować dopiero szablony, oba rozwiązania dadzą ten sam efekt, choć z punktu konstrukcyjnego sporo się różnią..

Jeśli starasz się pisać "obiektowo", nie używaj czegoś takiego jak global. Skoro upierasz się przy szablonach, dlaczego nie skorzystasz chociażby z gotowych rozwiązań takich jak Twig czy Open Power Template? Ten pierwszy system jest już zespojony z Symfony2, więc jeśli tego frameworka zacząłbyś się uczyć masz wszystko na miejscu.

No właśnie nie chcę używać global, stąd moje pytanie. Rozumiem jak możliwośći dają gotowe rozwiązania jednak stawiam sobie za cel przerobić już gotowy własny system napisany w dużej części proceduralnie na obiektowy, stąd moje pytania, bo dotychczas pisałem kilka klas głównych i w funkcjach wykorzystywałem ich zastosowania, a teraz chcę łączyć ze sobą klasy a nie wiem jak by to było najlepiej zrobić, czy takie ciągłe przekazywanie sobie obiektów w konstruktach nie jest zbyt obciążające dla samego przetworzenia przy wywoływaniu tych klas.

O przekazywanie obiektów nie masz się co martwić, lepiej spójrz na to z innej strony. Jak twój system ma się wydajnością w porównaniu do gotowych, sprawdzonych rozwiązań. Co gdy będziesz chciał osiągnąć nowe możliwości. Wynajdujesz koło na nowo, w dodatku jeszcze dość mocno uproszczone. Zaoszczędzisz czasu i nerwów, używając już napisanych i dobrych rozwiązań.

Rozumiem Twoje podejście, bo to co mówisz jest rozsądniejsze, choć sam chce sprawdzać swoje możliwości, już kupę lat się tym bawię i sprawia sporo radości zrobienie czegoś samemu a później udoskonalanie tego tak aby było coraz szybsze, bardziej niezawodne itd, to takie wyzwanie, w tworzeniu proceduralnym całkiem nieźle mi szło, obiektówki uczę się od niedawna i zdaję sobie sprawę z jego możliwości, może za bardzo się spinam bo w sumie na błędach się uczyć najlepiej, dlatego trzeba stworzyć coś raz, i później eliminować wady danego rozwiązania i optymalizować to co się da.

Wynajdowanie koła na nowo to są właśnie szablony, typu twig, opt czy smarty. Każdy z nich ma swoją składnie, do każdego trzeba uczyć się z osobna i tym podobne. Najlepsze szablony to czysty php, ewentualnie zrobić tak jak ja, jedno wyrażenie regularne które ci zmieni klamrę { na <?php oraz zamykającą klamrę } na ?> bo php sam w sobie udostępnia w przypadku bloków kodu alternatywny zapis. Pisałem o tym tutaj: http://forum.php.pl/index.php?showtopic=181343#entry887114 sam zrobiłem na własne potrzeby taki system szablonów i wydajnościowo stoi na takim samym poziomie co zwykła templatka zrobiona w php - czyli największy koszt wydajnościowy polega na includowaniu tego pliku.

@stroju co do twojego pytania, w jaki sposób chcesz przekazywać obiekty? Tzn który z wzorców projektowych sobie wybrałeś? Na swoje potrzeby korzystam z dependency injection, czyli przekazuje obiekty poprzez parametr. Mam jeden obiekt, w którym mam kilka obiektów które mogę później użyć, zamiast przekazywać kilka lub więcej parametrów do innego obiektu, przekazuje tylko ten jeden obiekt, w ten sposób w kolejnym obiekcie mam dostęp do wszystkich obiektów które przechowuje obiekt "Container". Tutaj masz opis po polsku: http://rekurencja.pl/php/symfony2/czym-jes...-injection.html

Tak racja, tylko że te koła są w jakiś sposób przemyślane i zaprojektowane. Co do gołego php, owszem, sam korzystam z tego i nie jest w cale źle, choć z drugiej strony szablony mają to do siebie, że możemy dzięki nim w łatwy sposób ułatwić sprawę front-endom.

@stroju

Nie za bardzo wiem, czy do nauki OOP najlepszy na sam początek jest system szablonów, który tak czy inaczej bez jakichś uzasadnionych argumentów nie warto pisać.

Dlaczego trudno jest Ci użyć gotowca i sprawdzeniu w czym jest Ci wygodny, a w czym Ci przeszkadza, czego brakuje. Ja proponowałbym na razie zostawić ten system co masz i ruszenie z czymś, a na czym zobaczysz choć zarys jak mniej więcej coś takiego może wyglądać.

No właśnie o to mi chodzi, czy przekazywać z zewnątrz czy tworzyć wewnątrz, i widzę że to całkiem niezła metoda która nie ogranicza możliwościami


Bo w zasadzie to jest pójście na łatwiznę, sam napisałem sobie wiele modułów, klas, kod działa dokładnie tak jak tego oczekuję, i nie działa źle bo przy mierzeniu czasów itd osiąga zadowalające wyniki, a to jakiś sukces, chcę poszerzać możliwości własnego kodu, i jego rozwijać, nie interesuje mnie wykorzystywanie gotowych rozwiązań, mimo iż mają większe możliwości i funkcjonalność, to zawsze wybiorę rozwój własnego kodu oraz to czego się nauczę podczas pisania, myślenia nad tym jak to napisać i w późniejszej fazie poprawy wydajności, to bardzo dobrze rozwija kogoś jako programistę. A nie da się ukryć że piszę dla siebie tylko to co jest mi potrzebne, nie ładuję masy kodu którego później nie będę używać

Nie będę Cię dalej przekonywał, ale ja nie widzę jakiejś szczególnej przeszkody. Nie wiem dlaczego zmieniając swój system szablonów, a korzystając z gotowca tracisz swój inny kod. O wiele lepiej tworzy się już z gotowym interfejsem, bo gdy czegoś potrzebujesz sam możesz to po prostu dopisać. Poza tym gdy udostępniałbyś swój silnik czy cokolwiek byś robił z połączeniem ZNANEGO systemu szablonów, ludzie nie musieliby się uczyć wszystkiego od nowa, bo z góry by wiedzieli z czym się to je.

Co do komunikacji między obiektami - DependencyInjection to chyba jedyne, rozsądne wyjście.

Czasami przy pisaniu własnych rzeczy, bez wcześniejszego spoglądnięcia na w miarę "poprawny" kod, możesz sobie tylko wbić złe nawyki.

No dlatego często przed rozpoczęciem pisania jakiegoś modułu sprawdzam gotowe rozwiązania i to co się wydaje najlepsze z różnych rzeczy wykorzystuję przy pisaniu własnych aplikacji.

Smarty to jest akurat super przemyslane.... zly przyklad daliscie.

Co do rozwijania własnego frameworka - bezsensowne rozwiązanie.

Na początku gdy nie bedziesz korzystał ze wszystkich funkcji oferowanych przez gotowy framework, to bedzie to dzialalo szybciej.

Dodajesz do projektu nowe i coraz to nowe funkcje, itd itd, framework twoj rowniez sie rozrasta az po pol roku co sie okazuje?

Ze wlasnie napisales wlasne uproszczone symfony/ZF - ktore wydajnoscia juz jest rowne temu gotowemu - bo sie rozroslo i sila rzeczy w koncu pojawila sie potrzeba na moduly ktore spowalniaja program.

Brniesz w to dalej i na koniec okazuje sie ze twoje rozwiazanie jest suma sumarum wolniejsze bo w takim symfony masz wbudowany mechanizm cache danych i kodu a u siebie musisz to zrobic, co wiecej musisz poswiecic na to duzo osobogodzin aby to dzialalo tak jak trzeba. Dodatkowo jestes do tyłu pare miesiecy ktore spedziles na pisaniu wlasnego frameworka. nikomu poza toba nie bedzie sie chcialo uczyc twojego api.

to powyzej to historia z zycia wzieta chcialbym cofnac czas ale juz za pozno

akurat jak przegladalem kod symfony 1.4 to znalazlem w nim sporo durnych rzeczy np doctrine - tworząc nowy obiekt Record (ten z Base<NazwaTabeli>) za kazdym razem ładuje do niego cala definicje tabeli. a co jesli w obiekcie są 3 wartosci? na opisanie struktury tabeli trzeba dodatkowych 7 czy 9 zmiennych. bezsens - jakby nie mogli tego zrobic statycznie w Peerze.

Ale to nie zmienia faktu ze nie marnujesz czasu na pisanie wlasnego kodu i co wazniejsze odpluskwianie go.

Pisanie wlasnego kodu bez wczesniejszego sprawdzenia czy ktos tego juz nie rozwiazal w optymalny sposob - to Antywzorzec projektowy. odsylam do wiki ;d

wdalem sie ostatnio w dyskusje na uczelni z kolegą z roku ktory dowalil ze Java i C# sa bez sensu i w ogole bo sa interpretowane i tylko C++ rządzi. Koledze kazalem sie na assemblera przerzucic bo C++ tez spowalnia i 40 lat temu gdy powstawał C ludzie mieli podobne obawy co do C a teraz sie je uwaza za najszybszy język.

Niby ten czlowiek ma racje... z punktu widzenia programisty - purysty moze i to zle ze programy spowalniaja.
Ale istnieje rowniez drugi punkt widzenia - inwestora zlecajacego napisanie programu - jego nie interesuje czystosc kodu ani jego predkosc często - poniewaz taniej bedzie dokupic drugi serwer niz zaplacic programiscie pietnascie tysiecy by poswiecil te pare miesiecy na zoptymalizowanie go. Nie zapominajmy ze inwestor musi rowniez pokryc podatki vat, zusy srusy wiec na koniec go to wyniesie 30 tys.

za ta kase to on sobie zrobi klaster. wiec inwestor nie chce zeby programista wynajdowal kolo na nowo tylko wzial to co juz jest, dopisal to czego nie ma i przyoszczedził. a wiekszosc nas chcac cos zarobic w tej branzy niestety bedzie musiala za tym podążać.

Widzisz, gdyby każdy tak podchodził do sprawy, na dzień dzisiejszy nie było by żadnego dostępnego fw, lub byłby dostępny jeden - po co więcej? Różnorodność jest wskazana



tworzenie swojego fw w celu nauczenia się oop, ma jak najbardziej sens, nawet jeżeli później nie będzie z niego korzystać. Gdzieś się tego nauczyć musi.



U siebie zrobiłem to tak że mam sobie klasę która ładuje wszystkie inne podstawowe klasy (konfiguracje, request, response, kontroler, router itp), i wrzuca instancje tych obiektów do kontenera. Popatrz jak to jest robione w innych frameworkach, każdy ma nieco inne podejście, wybierz sobie te które ci najbardziej będzie odpowiadać, i zacznij może nie od tworzenia tego swojego frameworka, ale od przemyślenia struktury, struktury katalogów, nazewnictwa plików, rodzaju konfiguracji (xml, ini, php, yaml i pewnie jeszcze kilka innych sposobów) i tym podobnych. Podpatrz rozwiązania wykorzystywane przez innych i pisz swojego fw

No i taki mam zamiar, chcę żeby wszystko działało tak jak działać powinno, także decyzję już podjąłem.

Obecnie nie tyle piszę framework ile po prostu stawiam aplikację od podstaw. Piszę klasy typowe dla architektury MVC. Kod opisujący działania pisze jako moduły. Przeniesienie tegoż na dowolny framework będzie wymagać ode mnie jedynie zastąpienia klas kontrolerów aby dziedziczyły po klasach jakiegoś framework'a + drobniejsze poprawki. Ostatnio się poirytowałem jak chciałem zaimportować bibliotekę z Kohany do obsługi bazy danych. Umieszczone są w folderze "modules" ale to nie są moduły, bo po wyciągnięciu ich z folderu okazuje się, że mają zależności z klasami ogólnymi frameworka. Straszna lipa. Podobnie jest w innych dużych i znanych framework'ach. Natomiast masa niepotrzebnych rzeczy we frameworkach, która jest uruchamiania skłoniła mnie do pisania własnego dedykowanego rozwiązania, bazującego na sprawdzonych i lekkich klasach tych np. z PEAR.