Witam,

Co jest lepszym rozwiazaniem? Singletone, czy przekazywanie go obiektom?
Dla przykladu:

[PHP] pobierz, plaintext 
<?php
// 1 rozwiazanie, klasa akcji:
 
public function execute(IController $oController)
{
  $oController->.......;
}
 
// 2 rozwiazanie, klasa akcji:
 
public function execute()
{
  $oController = Controller::getInstance();
  $oController->.......;
}
?>
[PHP] pobierz, plaintext 

Adrian.

Lepiej przekazywać jako argument funkcji. Pytanie tylko - po co przekazywać obiekt kontrolera akcjom? Nigdy nie spotkałem się z taką potrzebą, dlatego mnie to dziwi.

Dlaczego? Zobacz Mojavi - tam wszedzie sie tak robi.
Dlaczego Akcjom? Kontroler jest otoczka dla calej aplikacji. Kontroler udostepnia kontekst, ten zas request.

Siadam do kodu, jednak zmienie na singletone. dotychczas caly framework mial zorganizowany na zasadzie przekazywania kontrolera obiektom. Ale zauwazylem, ze moze to powodowac bledy - chociazby typu referencja, kopia obiektu. Oczywistym jest ze powinny byc to wszedzie referencje.

Adrian.

Hej.

Wydaje mi się że dużo lepiej jest przekazywać obiekt w konstruktorze po typie to daje możliwość podmiany implementacji danego interfejsu na inny - czyli jednym słowem zwiększa elastyczność kodu. Pracowanie na instancji tworzonej wewnątrz innej klasy powoduje że wymuszasz konkretny typ i w razie potrzeby modyfikować już istniejący kod - a nie o to chodzi w OOP.

Pozdrówka

anas

Z drugiej strony czesc obiektow otrzymuje w kontruktorze kontroler i nalezy sie do niego odwolac przez powiedzmy $this->_getController();. Czesc natomiast dostaje w wywolaniu metody execute().
Z nowu nie zawsze potrzebuje tego kontrolera, a jednak jest przekazywany w funkcji.

Najbardziej denerwuje mnie ta roznica w przekazywaniu w kontruktorze albo w execute();

No i na sam koniec - framework ma byc dla mnie maksymalnie wygodny.

witam

Jestem w trakcie kończenia innego rozwiązania. Jest klasa która jest managerem instancji ... zwraca obiekt wg jego nazwy oraz nazwy instancji (nazwa nie jest wymagana - może być utworzona automatycznie dla singletona - wtedy wiadomo że nie trzeba znać instancji, wystarczy nazwa klasy) ... może automatycznie tworzyć singletony (oczywiście jak ktoś z palca wywoła klasę która ma publiczny interfejs to dostanie obiekt ) lub nie pozwalać by dana klasa była używana jako taki ( za każdym razem zwraca nową instancję) ... po ustawieniu dodatkowych pól wewnątrz klasy (nie są wymagane) klasa tworzona może współpracować z managerem ... użycie odbywa się na zasadzie:

[PHP] pobierz, plaintext 
<?php
$obj = aeClassManager::getInstance('someSingletonClass', 'instanceName', true, array('param'=>'value'));
$obj2 = aeClassManager::getInstance(array('someSingletonClass', 'methodToGetSingletonInstance'), 'instanceName', true, array('param'=>'value'));
?>
[PHP] pobierz, plaintext 

ten manager nie jest związany z jakąś szczególną klasą ale może być pomocny przy dużej ilości obiektów (duża aplikacja intranetowa - w tym celu go opracowuje) ...

jeżeli uda mi się dziś skończyć to udostępnie w dziale gotowe skrypty może się komuś przyda ...

pozdrawiam

Skoro tak musisz robić, to bym się skłaniał do przekazywania albo przez konstruktor albo przy wywołaniu samej akcji. Którą metodę wybierzesz, to zależy od Ciebie.

Z drugiej strony jak dla mnie, to strasznie skomplikowany jest kontroler w mojavi. Nie prościej wyodrębnić wszystkie dane kontekstu do osobnego obiektu?

Owszem, kontroler Mojavi ma troche skomplikowanego kodu
Dlatego ja piszac wlasny framework sporo usunalem. Rozwiazanie z Mojavi ma jedna zalete, ktora mi sie podoba - kontroler jest sercem calej aplikacji. To jak skrzyzowanie z ktorego mozna pojechac w kazde miejsce.

Dodalem jeszcze metody zwracania loggera oraz bazy danych.

Adrian.

@orson: czy Twoje rozwiazanie to cos na zasadzie IoC? Jeśli tak to chętnie bym popatrzył jak rozwiązałeś przechowywanie relacji między obiektami. Jeśli nie to i tak ciekawi mnie Twoje podejście, czekam na skrypcik.

pozdrówka

anas

witam

Niestety nie jest to IoC :/ może kiedyś
Zapraszam do zapoznania się z kodem:
Temat: klasa Instance Manager zarzadzanie instacjami obiektow

pozdrawiam

@orson - byłbym wdzięczny gdybyś przedstawił mi zalety używania Twojego menagera do pobierania obiektu singletona w stosunku do zwykłego getInstance

-- edit --

@Prph - a nie powinno byc na odwrot, ze to akcje przekazuje sie do kontrolera, a nie kontroler do akcji?

Podpisuję się pod drugim pytaniem bigZbiga. W ten sposób tworzysz zbędne zależności pomiędzy akcjami a kontrolerem, kiedy akcja potrzebuje tylko dane z kontekstu, który można przekazać jako argument. Sam stosuję taką logikę i jakoś nigdy nie trafiłem na sytuację, która by wymagała zmiany mojego podejścia.

W zasadzie, to ja też chciałbym przeczytac opinie na temat "kto komu i co powinien przekazywac w tym ukladzie"

witam

@bigZbig: to jest rozwiązanie generalne. Pozwala ujednolicić sposób pobierania wszystkich obiektów ... nie tylko do singletownów ... nieraz wewnątrz metody musisz się odwołać do dblayera który nie może być singletonem (2 połączenia do 2 różnych baz w aplikacji) i zawsze chcesz dostawać określony obiekt ... podajesz nazwę klasy i instancję i zawsze dostaniesz ten sam obiekt co poprzednio ...

pozdrawiam

Hej.

Również uważam, że bez sensu jest tworzyć sztywne powiązania między obiektami - lepszym i dającym większe pole manewru jest rozwiązanie pozwalające bez ingerencji w już stworzony kod, manipulować istniejącymi obiektami. Właśnie dlatego pytałem o IoC. Generalnie ciekawym podejściem jest AOP - czyli programowanie aspektowe. Pokrótce chodzi o to aby do już istniejąycych obiektów, bez ingerencji w kod dorzucać nową funkcjonalność, podmieniać, wykonywać coś przed wywołaniem, lub po wywołaniu metody itd.

Przykład zastosowania:

Mamy sklep internetowy - wyliczamy cenę na podstawie kilku obiektów - cena bazowa -> podatek -> waluta = cena za produkt. Załóżmy że klient stwierdza po 3 miesiącach że chciałbym na wybrane produkty dorzucać promocję. Wtedy dzieki możliwości zdefiniowania funkcjonalności która wykona się ma obiekcie product, np.

$product->getProductPrice(Tax $taxObject, Currency $currencyObject, ProductDAO $productDAO);

zaraz po zwróceniu przez powyższą metodę wartości -> (Invoke.AfterReturning - definiuje kiedy ma sie wykonac nowa funkcjonalnosc). Po tym wszystkim należałoby zdefiniować dla jakich metod ma się to wykonać - np. Include("getProductPrice*") i mamy powiazania - tym wszystkim musi zarzadzac specjalnie przygotowane narzedzie.

W chwili obecnej w php ze wgzledu na trudna implementacje nie spotkalem sie z takim czyms - ale to ciekawy pomysl, ktory warto by bylo poruszyc w przyszlosci - to daje naprawde ogromne mozliwosci manipulowania kodem, bez koniecznosci ingerowania w juz istniejacy. Co myślicie o takim podejściu?

pozdrawiam

anas

Podejscie fajne, ale raczej jestesmy bez szans jesli chodzi o implementacje w php. Musialbylo by to chyba dosc absudarlnie wygladac gdyz trzeba by jakoby sprawdzac kazde operacje co spowoduje narzut kodu wiekszy niz to wszystko warte.

Wracajac do tematu - przekazyc kontroler do akcji. To tak jakby umieszczac generala w oddziale, dac Kalacha to reki i kazac walczyc, a on ma przeciez dowodzic

Wydaje mi się, że samo przekazanie obiektu kontrolera nie jest złe, bo w sumie chodzi o to, aby zbudowac aplikacje na kontrolerze. Z drugiej strony ciekwaszym i bardziej elastycznym rozwiązaniem będzie utworzenie klasy bramy udostępniającej obiekt kontrolera.

w teorii
user_code --> interface (obiekt lub statycznie) --> controller

Oczywiście można stworzy taki interfejs bezpośrednio w klasie, ale byłoby to zbytnie sprzęganie.
Wilk syty i owca cała. W każdym razie tak mi się wydaje.

W drugim przypadku (przekazywanie akcji kontrolerowi) możemy napotkac w dalszej perspektywie pewne trudne do przewidzenia problemy związane z budową samej akcji, która musi by zbudowana tak, aby rozumiała kontroler i była podatna na testowanie.

Ehh. To podobnie jak z prawami użytkowników - trzymac je razem z uzytkownikiem, czy w jakimś centralnym miejscu...a moze jeszcze inaczej.

Myślę, że tu jest generalnie problem z nazewnictwem bo kontroler u Prph'a jest jak podejrzewam specyficznym obiektem typu DTO (Data Transfer Object) służącym jedynie do transportowania informacji.

@orson - poczytaj na temat rejestru obiektów w Zend Frameworku. Moim zdaniem chyba chcesz przekombinować swojego menadżera.

To zalezy jak napiszesz framework.

Moj kontroller przypomina nieco kontroler Mojavi. Stanowi on "otoczke" calej aplikacji. Kontroler wykonuje akcjie. Te natomiast potrzebuja dostepu do danych post i get trzymanych w Kontekscie. A to kontroler posiada ow kontekst.

Jest to calkiem dobre rozwiazanie - wygodne. Wszystko co potrzebujesz jest w kontrolerze.

Adrian.

Prosty quiz

[PHP] pobierz, plaintext 
<?php
 
class user
{
	private static $oInstance=null;
 
	private $id=0,$lang='';
 
	public static function getInstance()
	{
		if(self::$oInstance==null) self::$oInstance=&new user();
 
		return self::$oInstance;
	}
 
	private function __construct()
	{
		$userData=httpContext::session()->getAttribute('user');
 
		if($userData{1})
		{
			$userData=unserialize($userData);
 
			$this->id=(int)$userData['id'];
			$this->lang=$userData['lang'];
		}
		else
		{
			$this->id=0;
			$this->lang=DEFAULT_LANG;
		}
	}
 
	public function isLoggedIn()
	{
		return ($this->id>0);
	}
 
	public function login($login,$pass)
	{
		$auth=authenticator::getInstance();
 
		$id=$auth->authenticate($login,$pass);
 
		if($id>0)
		{
			$this->id=$id;
			$this->lang=DEFAULT_LANG;
			return 1;
		}
		else
		{
			return 0;
		}
	}
 
	public function save()
	{
		httpContext::session()->setAttribute('user',serialize(array('id'=>$this->id,'lang'=>$this->lang)));
	}
 
	public function getLang()
	{
		return $this->lang;
	}
 
	public function logout()
	{
		$this->id=0;
	}
}
 
?>
[PHP] pobierz, plaintext 

I teraz w jaki sposob majac kontekst w kontrolerze obsluzysz taka klase jesli ona nie ma singletonu Bo wg mnie sztuka dla sztuki ( absurdem ) jest przekazywanie kotrolera z kontekstem do kazdej klasy

Ej, panowie, ale chyba znacie definicje Front Controllera prawda? Odpowiedzialność ciążąca na akcji powinna się sprowadzać tylko do wykonania pewnej operacji, cytując Fowlera:


Padły tu tez jakies zdania o IoC, w Springu, który korzysta w pełni z IoC jest element, który pełni funkcję front controllera - jest nim DispatcherServlet (pakiet spring.web.servlet).

Nie przekazuje go. Ale jezeli akcja go potrzebuje, to bierze go sobie poprzez Controller::getInstance();

Kontekst trzymam w kontrolerze, bo kontroler traktuje jak OTOCZKE aplikacji. I ta OTOCZKA ma kazdemu pozwolic wziac sobie co zechce. Jezeli potrzebuje parametru GET, niech poprosi o kontekst, a ten juz posiada HttpRequest.

Oczywiscie mozna zrobic Kontekst osobna klasa. Ale wtedy znowu byloby Context::getInstance->getRequest()...

Jak juz ktos powiedzial - ile osob, tyle roznych pomyslow. A ten pomysl nie jest akurat w pelni moj. Tak bylo bodajze w Mojavi, a i z Phienda2 cos zaczerpnalem.

Adrian.

Może warto zastosować tutaj rozwiązanie z javy? Np inversion of control (injection)


Kod:

[PHP] pobierz, plaintext 
<?php
function getmicrotime(){
   list($usec, $sec) = explode(" ",microtime());
   return ((float)$usec + (float)$sec);
}
function dump($val){
	/*
	echo '<pre>';
	var_dump($val);
	echo '</pre>';
	*/
}
function endTime($startTime){
	return getmicrotime() - $startTime;
}
 
class Manager{
	protected $config = NULL;
	protected $contener = array();
	public function __construct(){
		$this->config = parse_ini_file("config.ini", true);
	}
	public function create($name){
		if(isset($this->contener[$name])){
			return $this->contener;
		}
		if(!isset($this->config[$name])){
			throw new ClassNotExistException($name);
		}
		$class = new $name();
		if(isset($this->config[$name]['dep'])){
			$deps = explode(',', $this->config[$name]['dep']);
			foreach($deps as $dep){
				$method = 'set'.$dep;
				$class->$method($this->create($dep));
			}
		}
		if(!empty($this->config[$name]['singleton'])){
			$this->contener[$name] = $class;
		}
		return $class;
	}
}
 
class Class1{
	private $c2 = NULL;
	private $c4 = NULL;
	public function setClass2($c2){
		$this->c2 = $c2;
	}
	public function setClass4($c4){
		$this->c4 = $c4;
	}
	private static $_instance ; 
	public static function GetInstance() { 
		if (!isset(self::$_instance)){ 
			self::$_instance = new Class1() ; 
		} 
		return self::$_instance; 
	}
}
class Class2{
	private static $_instance ; 
	public static function GetInstance() { 
		if (!isset(self::$_instance)){ 
			self::$_instance = new Class2() ; 
		} 
		return self::$_instance; 
	}
}
class Class3{
	private static $_instance ; 
	public static function GetInstance() { 
		if (!isset(self::$_instance)){ 
			self::$_instance = new Class3() ; 
		} 
		return self::$_instance; 
	}
}
class Class4{
	private static $_instance ; 
	public static function GetInstance() { 
		if (!isset(self::$_instance)){ 
			self::$_instance = new Class4() ; 
		} 
		return self::$_instance; 
	}
}
class ClassNotExistException extends Exception{};
$startTime = getmicrotime();
$manager = new Manager();
for ($i = 0; $i < 100; $i++) {
	try{
		dump($manager->create('Class2'));
		dump($manager->create('Class4'));
		dump($manager->create('Class1'));
	}catch(ClassNotExistException $e){
		dump($e->getMessage());
	}
}
echo "Czas:".endTime($startTime).' (menager)<br/>';
 
$startTime = getmicrotime();
for ($i = 0; $i < 100; $i++) {
	$c2 = new Class2();
	$c4 = new Class4();
	$c1 = new Class1();
	$c1->setClass2($c2);
	$c1->setClass4($c4);
	dump($c2);
	dump($c4);
	dump($c1);
}
echo "Czas:".endTime($startTime).' (single)<br/>';
 
$startTime = getmicrotime();
for ($i = 0; $i < 100; $i++) {
	$s2 = Class2::GetInstance();
	$s4 = Class4::GetInstance();
	$s1 = Class1::GetInstance();
	$c1->setClass2($c2);
	$c1->setClass4($c4);
	dump($c2);
	dump($c4);
	dump($c1);
}
echo "Czas:".endTime($startTime).' (instance)<br/>';
?>
[PHP] pobierz, plaintext 

Co ciekawe działa podobnie szybko jak za każdym razem używać jawnie wywołania instancji, jedynie troszke dłużej trwa wczytywanie ini.

Czasy u mnie na lh:
Czas:0.0023281574249268 (menager)
Czas:0.0016329288482666 (single)
Czas:0.0024371147155762 (instance)


W javie (spring) działa to pięknie ale php z racji tworzenia od 0 za każdym wywołaniem czasami może warto poprostu nie przekombinować i tak wyszukane rozwiązania zostawić w spokoju.
Nie korzystałem z tego jeszcze w żadnym projekcie bo ostatnio nie robie wiele w php i stworzyłe tylko z ciakawości czy sie wogóle uda.

Hm... muszę przynać, że ciekawie to wygląda i nawet narzut czasowy jest do zaakceptowania. Sam będę musiał przemyśleć zastosowanie czegoś takiego u siebie.

Moim zdaniem wszystko zalezy od konstrukcji aplikacji. Jesli chodzi o jakies schematy obiektow ktore beda odpalane, czyli obiekty maja takie same nazwy metod to mozna przekazywac. Ale ogolnie ja sie przykladam do przekazywania instancji. I mozna to robic w roznoraki sposob. Albo poprzez Magazyn albo przez singletone. Ja uzywam singletone. Jest to o tyle wygodne ze jesli chce przekazac instancje obiektu w parametrze, to musze miec ja juz wywolana.
Jesli nie stworzylem obiektu jakies klasy bo nie była potrzebna wczesniej, to musze stworzyc obiekt tylko po to zeby go przekazac. Wiec po co ? skoro w metodzie ktora wymaga obiektu moge odwolas sie do getInstance() i juz mam. Sadze ze jest to wygodniejsze. Przy jakichkolwiek zmienach nie musze pamietac o tym ze wymagam jakiegos obiektu w atrybucie.
Przy okazji, jesli mam grupe roznych modeli, i potrzebuje pobrac 3 modele do akcji, to bedziesz je przekazywac w atrybutach ? Dziwnie by to wygladało.

Ale czy w tym wypdku o którym mówisz Sh4dow, to nie może się zdazyć tak, że jeśli będziesz miał dwie klasy (potrzebujące tego samego obiektu) z metodami getInstance(), to każda powoła do życia obiekty tego samego typu, ale różne?

@Cysiaczek - jesli to jet klasa Singleton (poprawnie zaimplementowana) to w ramach jednego wywolania nie ma szansy na powolanie do zycia wiecej niz jednej jej instancji.

Tak. Zdaję sobie z tego sprawę - mimo to zastanawiam się nad samym mechanizmem jawnego wywołania instancji w ciele klasy. przy singletonie jest ok, ale gdzie indziej? Po prostu pytam.

Ale w czym problem? Zalezy od ciebie czy przekazesz obiekt do klasy czy wywolasz go wewnatrz niej. Wzorzec budowniczego np. zaklada z definicji tworzenie instancji wewnatrz klasy bo klasy te maja wlasnie takie przeznaczenie.

Klopot z wywolywaniem Singeltona wewnatrz klasy polega na tym ze wywolujesz konkretna klase. Nie jej rozszerzenie np, ale wlasnie te klase. No chyba, ze przekazujesz do swojej klasy nazwe klasy bedacej singletonem, ale to juz chyba lepeiej przekazac obiekt.

Aha. Własnie do tego zmierzałem - po co "psuć" klasę trzymając tam nazwę innej klasy. Lepiej chyba od razu przekazać obiekt. Zastanawia mnie jeszcze coś takiego.

[PHP] pobierz, plaintext 
<?php
class somethingCool{
.../
private $_classMagicBox; //array
 
public function assignClassName($className){}
 
private function getInstance(){}
 
.../
 
}
?>
[PHP] pobierz, plaintext 

Czy to byłoby dobre do wywołania/utrzymywania potrzebnych pierdół?

Singleton jest zły. Dlaczego? Jest to niemalże to samo co global. Singleton jest po to by mieć 1 instancje a nie po to by nie przekazywać obiektów!
Inversion of Controll idzie dalej, zapewnia obsługę obiektów. Kontener IoC możę się zachowywać jak fabryka i wypluwać kolejne instancje albo trzymać tylko 1 instancje. Dostęp do usług (np połączenia z bazą) jest tylko w tych miejscach, gdzie przekazaliśmy instancję kontenera.

podejrzewam że IoC może sie nie podobać osobom które mają np pare klass obsługujących cały kod. Np klassa User powinna mieć dostęp do obketku Groups ale jeśli ktoś trzymałby w tej klasie dodatkowo tworzenie miniaturki usera, zarządznaie wiadomościami i jeszcze coś wówczas rzeczywiście może być sporo niepotrzebnych stworzonych obiektów. W javie lazy-init pomaga gdzie obiekt jest tworzony dopiero gdy jest potrzebny.


Takie rzeczy powinny wyjść w testach.

Tak jak pisze Splatch IoC zapewnia większe bezpieczeństwo, kodu. Pozatym klassy są mniej z sobą powiązane przez co w przyszłości prościej można je wykorzystać w innym projekcie.