Witam,

jestem po lekturze naprawdę wielu tematów na tym forum, w okręg moich zainteresowań weszła także książka "PHP5 Obiekty, wzorce, narzędzia".
Mimo to mam problem co do ułożenia odpowiedniej klasy. Moje problemy:

1. Czy w klasie np. do obsługi newsów powinna znajdować się metoda do wyświetlania konkretnego newsa/newsów jeżeli nie stosuje ścisłego MVC (chce napisać stronę zintegrowaną z innym skryptem od którego będę używał kilka klas i funkcji, m.in. do wyświetlania w przeglądarce html)? Jeżeli nie to powinienem zrobić dla niej osobną funkcję (bez klasy)?

2. Idąc dalej przykładem klasy do obsługi newsów chciałbym zapytać czy lepiej definiować ID newsa już w konstruktorze czy ustalać go manualnie przez metodę np. setId()?

3. Czy opłaca się stworzyć osobną metodę do dodawania elementów do tablicy z danymi newsa (np. addParam($key, $value), czy wyjdzie na to samo (w sensie obiektowym) przekazując pełną tablicę prosto do metody np. update()?

Poniżej zarys klasy:

[PHP] pobierz, plaintext 
<?php
class News {
	private $newsId	 = 0;
	private $params		= array();
 
	public function setId($id) { } // Ustawia id newsa na którym chcemy operować
	public function submit() { } // Jeżeli newsId > 0 to aktualizuje, jeśli odwrotnie to tworzy nowy rekord
	private function insert() { }
	private function update() { }
	public function delete() { }
	public function addParam($key, $value) { } // Dodaje parametry typu nazwa newsa, autor, treść, źródło do tablicy danych
	public function print() { } // Wyświetla newsa, jeżeli ustaliliśmy Id do wyświetla wybrany news, jeżeli nie to
 wszystkie
	private function printSpecific() { } 
	private function printAll($perPage) { }
}
?>
[PHP] pobierz, plaintext 

Jest tu sens OOP? Co zmienić aby było lepiej?

Pozdrawiam i z góry serdecznie dziękuje za wyjaśnienia!

Generalnie to zależy od ciebie, ale jeżeli obiekt News reprezentuję jednego newsa to nie widzę zastrzeżeń, żeby było to w konstruktorze - będzie bardziej czytelnie.

[PHP] pobierz, plaintext 
<?php
$news = new News($id); // wygląda przystępniej niż..
 
$news = news News();
$news->setId($id); // .. to, praawda?
 
// Ewentualnie możesz postawić na czytelność metod...
 
$news = news News();
$news->getById($id); // identyczne jak w drugim przykładzie, ale czytelniejsze.
 
// .. a nawet tak
 
$news_2 = News::getById(2); // metoda statyczna, zwraca obiekt News
 
// czy
 
$news = News::getAllByPage($page, $per_page); // zwraca tablicę obiektów News, które zostały wypełnione danymi zewnętrznie
?>
[PHP] pobierz, plaintext 

Możesz nawet stosować hybrydy, czyli jeżeli sam tworzysz News to $id w konstruktorze ( i tam wyciągasz dane z bazy), a jak chcesz kilka to tworzysz metodę, która zwraca tobie tablicę obiektów News (ale nie wywołujesz ich tam, przez $id w konstruktorze, tylko wyciągasz dane jednym zapytaniem w tej metodzie i "manualnie" te obiekty wypełniasz).

@LBO
takie pytanko

czy jest jakas roznica miedzy



a tym


czy po prostu jak kto woli

Jest różnica, bo w metodach statycznych opakowujesz Managera. Kod jest bardziej przejrzysty jak dla mnie.
To są niewielkie różnice w wydajności, ale do tych operacji, które nie są związane z żadną konkretną instancją, lepiej zaprząc statyczną część klasy.

Ogólnie chyba

[PHP] pobierz, plaintext 
<?php
$news_2 = NewsPeer::getById(2);
?>
[PHP] pobierz, plaintext 

wykorzystanie DAO i AR ;] Czy jakoś tak to szło, mi się zawsze pojęcia mieszają.

Po co te klasy statyczne? Mi się na przykąłd cały kod strony ze strukturą, kategoriami i jakimś tam menu generuje w 50ms. Dojdę moze do 100ms ale to i tak nic nie zmienia bo złożoność obliczeniowa zawsze będzie rzędu On czyli liniowa. Co one własciwie dają ? (w sensie wydajnościowym)

@Black-Berry
A co daje podejście obiektowe, przecież to też jest gorsze wydajnościowo niż strukturalny kod ;]
Zwiększa czytelność i elastyczność kodu, zasada że klasy i ich obiekty mają jedno konkretne zadanie, po to się rozbija na funkcjonalność. Klasa News ma się zając konkretną aktualnością, nie obchodzi jej skąd się wzięła, czy jest częścią większego zbiory.

Można i tak (Propel-way), ale czy przy tak niewielkim zastosowaniu trzeba rozbijać to na dwie klasy na tabelę?



Może nie dają nic, ale są bardziej czytelne? Po co tworzyć obiekt, skoro taki manager (jaki reprezentują metody statyczne) jest bezstanowy.

To był przykład, jak masz metody pobierające np. najnowsze News'y losowe, czy jakiekolwiek zbiory, to umieszczasz to tam, masz w jednym miejscu wszystkie metody pobierania News'ów, dzięki temu, jak jest wymagana poprawka, zmiana funkcjonalności, masz jedno miejsce do edycji (albo dobry punkt zaczepienia, przy większych zmianach). Czyli taki Peer operuje ogólnie na News'ach, a obiekty klasy News na konkretnym elemencie, i tam masz metody np. do pobierania autora, czy co tam będzie potrzebne, przy operowaniu na konkretnej News'ie.

P.S. Hibernate ma jeszcze bardziej to rozbite.

Chodziło mi o coś wręcz przeciwnego. Myślałem, że LBO pije do tego ze klasy statyczne są szybsze. Wogóle to mam mętlik straszny bo każdy mówi co innego: jedni ze singletny są złe, inni ze rejestry, jeszcze inni ze nie wolno używać globalsów... Pooli dochodze do wniosku że nikt ni ma racji, a liczy się tylko wygoda. Zresztą jak ma być 1 obiekt z danej klasy tylko to trzeba napisać to w komentarzach A jak ktoś jest na tyle głupi żeby tworzyć 2 klasy dbDriver to już jego problem Od dzisiaj tylko czyste obiekty bez żadnych udziwnień singletonami i klasami statycznymi stosuję... Od jutra bo dzis juz idę w kimę... sory za odejście od tematu poprostu musiałem się wyżalić Pozdrawiam wszystkich.

Heeh, ja to wiem. Pytam się czy takie rozbicie jest konieczne? Jak sam mówisz Hibernate ma jeszcze większy poziom decouple'ingu niż Propel - czy to znaczy, że Propel ma się stać jeszcze bardziej skomplikowany, bo trzeba naśladować Hibernate (abstrachując od związku z Torque )?



Maja rację



Też, ale nieraz ważniejszy jest porządek w kodzie. Można sobie nieźle nabruździć z takim czysto-praktycznym podejściem.



Bo chyba nie do końca rozumiesz pojęcie Singletonu mam wrażenie. Singleton nie jest tożsamy z dokładnie jednym obiektem danej klasy.

Globalsów się nie używa... bo nie
Singletona się używa ostrożnie - w uzasadnionych przypadkach (np. obiekt kontrolujący bazę danych)
Rejestru się używa i jest on dobrym wzorcem - trzeba mieć niepokolei w głowie, żeby twierdzić inaczej
Klasy statyczne stosuje się tam, gdzie trzeba (co już powiedzieli moim przedmówcy) i nie jest to żadne udziwnienie

Masz mętlik w głowie? Świetnie, powtarzaj mantrę "wszystko zależy od okoliczności, wszystko zależy od okoliczności, wszystko zależy od okoliczności" - codziennie przez godzinę

Pozdrawiam.

Zgodzę się

Nie zgodzę się, a co jak chcesz mieć parę różnych połączeń w jednej chwili? Już miałem przyjemność z singletonem, więc musiałem napisać okropny kod, bo nie było czasu na przerobienie tej konstrukcji. (Propel jak wiesz pozwala na wiele połączeń, mimo że jak się używa jednego,to jest to nie zauważalne)

Czy takim dobrym, to bym nie był pewien, ale na pewno lepszy niż Globals

Tylko wątpię aby to pomogło ;]
@Black-Berry
Dwie rzeczy, doświadczenie (praktyka) z różnymi rozwiązaniami, powie Ci co jest lepsze. Bo to jest lepsze, co potem pozwala Ci szybciej i wygodniej pracować. Ponieważ te wszystkie rzeczy, OOP, Design Patterns itd. są po to, aby w przyszłości korzystanie z tak napisanych elementów było łatwo korzystać, i jak już trzeba coś dodać/zmienić, aby to była chwila.
Ale to nie jest tak, że jest jedno poprawne rozwiązanie, każdy programista ma swoje preferencje i stąd wynikają te różnice, ale do ogólnych spraw raczej większość jest zgodna.
Niestety, tylko doświadczenie w pisaniu i korzystaniu z różnych rozwiązań da Ci pewną pewność jak to rozwiązać... Więc czytaj, korzystaj, pisz i analizuj, jak się sprawują jakieś rozwiązania, próbuj różnych, ogólnie polecamy Propel, Synfony (może jeszcze parę) dla tego, że są przyzwoicie napisane, jak będziesz z nich korzystać, to zobaczysz że jest to wygodne i będziesz mógł podejrzeć jak inni to robią.

@Sedziwoj Z tego co mówisz pośrednio wynika, że najlepiej przekazywać wszystko jawnie w konstruktorze bo moze się okazać, że chcesz np mieć osobne połaczenie z bazą dla przykładowego newsMenager'a. Idąc dalej tym tropem dobrze by było nie przekazywać za każdym razem 15 obiektów tylko już lepiej wrzucić wszystko do rejestru i przekazywać tylko jeden obiekt rejestru. Obiekt główny po którym dziedziczy każdy inny już sobie poustawia odpowiednie pola... Ale zauważ że w ten sposób tuszujesz tylko globalność niektórych obiektów.

No i moje dalsze rozumowanie: Po co tuszować? Nie lepiej w konstruktorze obiektu głównego i tylko w nim użyć słówka kluczowego global aby przypisać globalne obiekty do pól dziedziczących? Wtedy już nic nie musze przekazywać w konstruktorach, no i nie chowam śmieci pod dywan za pomocą rejestru

W lesie masz rozrzucone kuleczki, teraz je znajdź trudne, co nie?
A wyobraź sobie że masz teraz do każdej przywiązaną nitkę, tak że zbiegają się wszystkie w Twoich dłoniach, o wiele łatwiej znaleźć?

Ogólnie zaplanowanie tak aplikacji, aby mieć zawsze dostęp do rzeczy potrzebnych w danym miejscu i nie robić tego na około, to jest trudne zagadnienie.

Dlaczego tak wszyscy nie lubią Registry? Przecież jest to wzorzec, który stosowany umiejętnie rozwiązuje np. problem BlackBerrego z 15 obiektami, które chce przekazać.
Inicjujesz rejestr, dodajesz do niego obiekty kojarząc je w kolekcje, potem tylko do konstruktora leci konkretna kolekcja - jako jeden parametr. Konstruktor sobie to rozpakowuje i voila!

Taki rejestr może kojarzyć obiekty na podstawie implementowanych interfejsów, co jest kolejnym przykładem ich zastosowania. Omijasz wówczas jawne przypisywanie do kolekcji.

Pozdrawiam.

Chyba mnie właśnie nawróciłeś

Można prosić o jakiś manual do poczytania? O co chodzi z tymi kolekcjami? Chodzi tylko o grupowanie w logikę czy to ma też względy wydajnościowe jeśli nie przekazuję całego rejestru?

@Cysiaczek
Bo taki Registry, wydaje mi się niedaleko od wzorca Singleton ;]
Po prostu, jak nie wiem jak coś zrobić go wykorzystam...
Ale to jest jałowa dyskusja, bo wydaje mi się że na razie do kompromisu się nie dojdzie. Nie mówię że stosowanie Registry jest złe, po prostu mi się on bardzo nie podoba.

Co w takim razie robisz z obiektami globalnymi?

Jedna sprawa to skorzystać z np. generatora miniaturek, który po prostu ma zrobić swoje, a inna sprawa to korzystanie z dostępu do np. bazy danych które gdzieś jest inicjalizowane, czy danych z GET/POST/itd. które mają być dostępne w akcjach. Po prostu większość rzeczy da się przekazać do obiektu w jakiś inny sposób, np. wykorzystując warstwę abstrakcji, Registry jest o tyle brzydki że trzeba wiedzieć co w nim jest.

@sedziwoj - Tak? To patrz

Wybaczcie niedoróbki, ale to tylko mała prezentacja oparta o proste tablice.

[PHP] pobierz, plaintext 
<?php
interface Basic{}
interface Advanced{}
 
class Config{}
class fwConfig extends Config implements Basic{}
class appConfig extends Config implements Basic{}
class moduleConfig extends Config implements Advanced{}
 
 
class Registry
{
	static public $interfaces=array('Basic', 'Advanced'); // najlepiej zautomotyzować
	static public $collection=array();
 
 
	static public function add($obj)
	{
		foreach(class_implements($obj) as $iface)
		{
			if(in_array($iface, self::$interfaces))
			{
				self::$collection[$iface][get_class($obj)]=$obj;
			}
		}
	}
 
	static public function getFor($obj)
	{
		$data=array();
		foreach(class_implements($obj) as $iface)
		{
			if(in_array($iface, self::$interfaces) && is_array(self::$collection[$iface]))
			{
				$data=array_merge($data, self::$collection[$iface]);
			}
		}
		return $data;
	}
 
	public static function getBasicCollection()
	{
		return self::$collection['Basic'];
	}
 
	public static function getAdvancedCollection()
	{
		return self::$collection['Advanced'];
	}
 
	public static function getAll()
	{
		return self::$collection;
	}
}
 
class News implements Basic,Advanced
{
	public function __construct()
	{
		extract(Registry::getFor($this));
		print_r($fwConfig);
	}
}
 
$f=new fwConfig();
$a=new appConfig();
$m=new moduleConfig();
 
print '<pre>';
Registry::add($f);
Registry::add($a);
Registry::add($m);
$obj=new News();
print '</pre>';
?>
[PHP] pobierz, plaintext 

@BlackBerry - Proszę, Twoje globale

Pozdrawiam

Ja nadal uważam, że Rejestr nie jest najlepszym pomysłem i można się zawsze bez Niego Obejść. Natura programowania obiektowego jest enkapsulacja, a co za tym idzie mądre zarządzanie udostępnianiem ukrytych danych.
Bardzo łatwo można tak zaprojektować system/framework żeby ukrywał specyficzne dane i udostępniał tam gdzie potrzeba.

Fakt do samego konfigu jako klasa statyczna jak najbardziej jestem za, ale jak zauważyłem duża część programistów umieszcza w Rejestrze absolutnie wszystko - od danych konfiguracyjnych po jakieś specyficzne obiekty z logiką, która nie jest potrzebna w każdej części systemu. To świadczy o złej naturze Rejestru.

edit: ucięło mi część tekstu przez moją nieuwagę.

@.@ śliczne... Nie będę może polemizował bo jedyne co mi się nasuwa to że to cholernie skąplikowane a jedno słówko kluczowe global robi to samo. Ale masz 3,5k postów i śliczną konstrukcję rejestru więc pewnie się na tym znasz lepiej. Jak sobie przemyślę głębiej to pogadamy

Zwróć uwagę na użycie, nie klasę, bo klasę masz raz napisaną, a potem ją używasz.
Pomijam fakt że nadal uważam to za coś co mi się nie podoba, ale nie chce mi się wnikać chwilowo w argumenty, LBO jak widzę sobie nieźle radzi

@Cysiaczek A tak z ciekawości to czy problem Sedziwoj'a o potrzebie 2 połaczeń z bazą byłby możliwy do rozwiązania w przypadku zastosowania Twojej konstrukcji rejestru? Np tak:

[PHP] pobierz, plaintext 
<?php
	$dbDriver2 = new Db_Driver();
	$obj = new News();
	$obj->setDbDriver($dbDriver2);
?>
[PHP] pobierz, plaintext 

Zakładam że defaultowy dbDriver jest dodany wcześniej już do rejestru i chce go teraz podmienić.

W takim przypadku jestem za Zendowym rozwiązaniem

[PHP] pobierz, plaintext 
<?php
Db_Driver::setDefaultDriver($dbDriver);
?>
[PHP] pobierz, plaintext 

i można się obyć bez rejestru. Chociaż to też przypadek ekstremalny i można to rozwiązać dużo zgrabniej.
W prawdziwych systemach jest manager bazy danych - która trzyma identyfikowalną konfiguracje do rożnych połączeń i łączy się wtedy, kiedy potrzebuje (lazy load).
Przyzwyczaiłem się, że różne części frameworka są bardzo autonomiczne i zazwyczaj potrzeba tylko konfig a cała magia dzieje się pod powierzchnią. Jest to zarazem wygodne i śliczne rozwiązanie.

Chcesz zob aczyć coś magicznie ślicznego? To patrz na moje 'zgrabne' rozwiązanie. Prosze się nie śmiać

[PHP] pobierz, plaintext 
<?php
	abstract class Main_Object
	{
		protected $settings;
		protected $language;
		protected $dbDriver;
		protected $session;
		protected $userGroup;
		protected $log;
		protected $userGroupManager;
		protected $structureManager;
		protected $rootManager;
		protected $nodeManager;
 
		protected function __construct()
		{
			global $userGroupManager;
			$this->userGroup = $userGroupManager;
			global $mainSettings;
			$this->settings = $mainSettings;
			global $languageManager;
			$this->language = $languageManager;
			global $dbDriver;
			$this->dbDriver = $dbDriver;
			global $mainSession;
			$this->session = $mainSession;
			global $mainLog;
			$this->log = $mainLog;
			global $userGroupManager;
			$this->userGroupManager = $userGroupManager;
			global $structureManager;
			$this->structureManager = $structureManager;
			global $rootManager;
			$this->rootManager = $rootManager;
			global $nodeManager;
			$this->nodeManager = $nodeManager;
		}
	}
?>
[PHP] pobierz, plaintext 

This is magic baby

o_O mój boże

Zrób z tego obiekt kontekstu. Umieść gdzieś w systemie i udostępniaj gdzie potrzeba:

[PHP] pobierz, plaintext 
<?php
$this->context->getDatabaseManager->getConntection('nazwa_polaczenia');
$this->context->getSessionMager->write($dane);
?>
[PHP] pobierz, plaintext 

To jest Magia...

A czy taki obiekt kontekstu przekazywany do kazdego konstruktora to nie to samo co rejestr na który tak narzekałeś ?

Nie bo w pełni kontroluję gdzie on jest dostępny.

No to teraz już coś rozumiem... Ale w całym frameworku jest tylko jeden obiekt kontekstu? czy są rózne grupy tak jak w przykładzie Cysiaczka ?

Hmmm... jeden i tylko jeden. Cały myk w tym, że różnice powinny zależeć od Ciebie. Czyli nie ustawiaj tych wszystkich Managerów z globali - ostatnio modne jest tzw dependency injection, czyli (przykład):

[PHP] pobierz, plaintext 
<?php
class Main_Object {
 
	 protected $dbDriver;
 
	 public function setDbDriver(dbDriver $dbDriver)
	 {
		 $this->dbDriver = $dbDriver;
	 }
 
	 public function getDbDriver()
	 {
		 return $this->dbDriver;
	 }
 
}
?>
[PHP] pobierz, plaintext 

Dostrzegasz jak dużą kontrolę zyskujesz dzięki temu

@LBO: Dostrzegam Powiedz mi jeszcze po co Ci są potrzebne klasy statyczne skoro mogłaby teoretycznie istnieć potrzeba dublowane nawet settingsów.

A kiedy dublujesz settingsy? Powiem Tobie - kiedy masz np. różne środowiska (produkcyjne, developerskie,w_domu_do_podgladania). Ale generalnie używasz tylko Tych, które są w tym momencie potrzebne (czyli na dane środowisko). Czy konkludując: sobie je sam ustawiasz dla środowiska, tylko te które potrzebujesz. I niby jest dublowane, ale jednak nie. Bo nie wszystkiego potrzebujesz. Architektura oprogramowania właśnie na tym polega, żebyś umiał rozgraniczyć i dobrze takie coś zaprojektować.

A klasy statyczne - są przydatne np. jako zastępnik funkcji np.

[PHP] pobierz, plaintext 
<?php
// to jest czysto abstrakcyjny przykład, nie sugeruj się tym
class HtmlTools
{
	 public static function escape($text)
	{
		 // htmlspecialchars() the output
	}
 
	public static function link($url, $text, $alt)
	{
		// generate HTML link
	}
}
?>
[PHP] pobierz, plaintext 

Są przydatne kiedy potrzebujesz czegoś bezstanowego. To, że możesz zrobić z klasy statycznej cos co przypomina pełnoprawny obiekt (używając atrybutów statycznych etc) nie znaczy, że to musisz robić.
W Pythonie chyba można dynamicznie zmieniać definicje klas, prawda? Ale czy to znaczy, że trzeba tego uzywać, skoro to jest gwarantem śmietnika w kodzie?

@LBO wszystko super. Metoda Cysiaczka trochę przestaje do mnei przemawiać. Kontekst wydaje się być bardziej odpowiedni. No chyba że tak zaawansowany rejestr to już wyższa szkoła jazdy i nadaje się do systemów operacyjnych, a na poziomie CMS-ów i frameworków kontekst sprawia wrażenie przyjaźniejszego. Co do klas statycznych to nie wiem, funkcje też są fajne ale faktycznie czasem dobrze byłoby je w coś opakować. Takie opakowane funkcje też sie przekazuje kontekstem tak ?

Z wykorzystaniem klas statycznych to był tylko luźny przykład - to jest moje zastosowanie.
Pamiętaj jesteś programistą i sam o wszystkim decydujesz - złotego środka nikt nie poda Tobie na tacy.

A takie opakowane funkcje przekazuje się includem albo autoloaderem podstawy

To, co pokazałem, to pewna wariacja, a nie sprawdzony sposób
Od Rejestru do Kontekstu jest niedaleko. W zasadzie można powiedzieć, że oba są Rejestrami, albo oba są Kontekstami. Granica jest płynna. To samo uzyskasz umiejętnie rozprowadzając Singletona po systemie - wówczas on również jest kontekstem.

Aha. Ilość postów nie jest wyznacznikiem posiadanej wiedzy . Cały postęp polega na kwestionowaniu tzw. autorytetów

Pozdrawiam.

Dzięki za rady:) Wezmę je pod uwagę przy pisaniu następnej wersji swojego systemu b teraz to juz na wszystko za późno

OT:
Czy ja wiem, właśnie osiągnąłem 4 cyferki i byłoby mi na rękę gdyby jednak tak heheh

Pozdrawiam, Alan

Prawie robi wielką różnicę ;]
Nie zauważyłeś ważnej różnicy, a mianowicie wyszczególnienia elementów i możliwości ograniczenia co jest dostępne w danym miejscu.

P.S. OT to ja wypadam marnie w ilości ;(