Michał Sosnowski

Michał Sosnowski grafik/webmaster

Temat: OOP - te same pole kilku obiektów

Mam kilka utworzonych obiektów tej samej klasy i powiedzmy są ustawione pola n.: Error czyli istnieje kilka obiektów tej samej klasy z polem Error w którym siedzi jakiś komunikat..

Chciałbym szybko wyświetlić listę Error'ów wszystkich obiektów który takowy ustawiony mają..

konto usunięte

Temat: OOP - te same pole kilku obiektów

Na dobrą sprawę najlepiej by je było gdzieś "zarejestrować". Coś w tym stylu:


class CommonData {
protected $objects = array();

public function register(Object $Obj) {
$this->objects[] = $Obj;
}


public function getErrors() {
$errors = array();
foreach($this->objects as $Obj) {
if(!property_exists(get_class($Obj), 'error')) { continue; }
$errors[] = $Obj->error;
}
return $errors;
}
}


Klasa ma o tyle sens że zarejestrujesz w niej co chcesz ale zwróci tablicę "błędów" tylko z tych które mają atrybut error.

Taki przykład. Inna możliwość (chyba nawet prostsza) to jakaś tablica statyczna która by przechowywała poszczególne errory + wygenerowany w konstruktorze identyfikator instancji klasy która posłuży jako klucz. To przykład z życia wzięty (tzn widziałem coś takiego w działaniu). Ale sam staram się unikać sytuacji gdy jeden obiekt wpływa na drugi. Zwłaszcza kiedy to nie jest do niczego potrzebne jak zapewne w tym wypadku.Dariusz Półtorak edytował(a) ten post dnia 16.12.11 o godzinie 11:28
Wojciech Soczyński

Wojciech Soczyński Programista
eksplorator -
blog.wsoczynski.pl

Temat: OOP - te same pole kilku obiektów

Michał Sosnowski:
Mam kilka utworzonych obiektów tej samej klasy i powiedzmy są ustawione pola n.: Error czyli istnieje kilka obiektów tej samej klasy z polem Error w którym siedzi jakiś komunikat..

Chciałbym szybko wyświetlić listę Error'ów wszystkich obiektów który takowy ustawiony mają..


class Error {

private static $_instances = array();

private $_errors = array();

private __construct(){}

public static factory(){
$inst = new self();
self::$_instances[] = $inst;
return $inst;

}

public function addError($error){

$this->_errors[] = $error;
}

public function showErrors(){
return $this->_errors();

}


public static showAllInstanceErrors(){
$res = array();

foreach(self::$_instances as $inst){

$res = $res + $inst->showErrors();
}

return $res;
}
}


//usage


$error1 = Error::factory();
$error2 = Error::factory();

$error1->addError('aaa');
$error2->addError('bbb');

$res = Error::showAllInstancesError(); // wynik array('aaa','bbb');




Tak na szybko ;)Wojciech Soczyński edytował(a) ten post dnia 16.12.11 o godzinie 12:01

konto usunięte

Temat: OOP - te same pole kilku obiektów

Wojciech Soczyński:
Tak na szybko ;)

Tak z ciekawości (bo przykład podobny do tego który opisałem wyżej) to jak Wam się widzą takie rozwiązania ? Tzn wbudowanie w obiekt czegoś co jest potrzebne tylko w tym konkretnym wypadku i właściwie z samym obiektem nie ma nic wspólnego (mam nadzieje że rozumiecie o co mi chodzi).

Taki rejestr ma tą przewagę że dorzucić możemy referencję dowolnego obiektu i masowo wyciągać z nich możemy co chcemy. Należy zauważyć że chcąc wyciągać jeszcze jakieś dane musimy rozszerzać WSZYSTKIE klasy które będą daną rzecz powielały (jak np ten komunikat błędu) gdzie w innym wypadku poszerzamy taki rejestr obiektów o nowe możliwości współpracy z nimi.

Więc ? Co myślicie ?

konto usunięte

Temat: OOP - te same pole kilku obiektów

Dariusz Półtorak:

...
if(!property_exists(get_class($Obj), 'error')) { continue; }
$errors[] = $Obj->error;
...
Przekombinowany ten kod trochę. Można prościej:

if (isset($Obj->error)) {
$errors[] = $Obj->error;
}

konto usunięte

Temat: OOP - te same pole kilku obiektów

Tomasz K.:
Dariusz Półtorak:

...
if(!property_exists(get_class($Obj), 'error')) { continue; }
$errors[] = $Obj->error;
...
Przekombinowany ten kod trochę. Można prościej:

if (isset($Obj->error)) {
$errors[] = $Obj->error;
}

Hehe :-) Można. Moje zboczenie. W momencie jak $Obj->error będzie zawierał wartość null (w moim systemie domyślna wartość to często null i taka by była gdyby komunikatu nie było) to isset() zwróci wbrew logice false (w końcu zmienna jest i ma wartość null) więc skrypt pominął by kilka obiektów które błędu nie mają.
Gdzie jak wszystko to wszystko :-) Metoda którą podałem nie ma tego problemu. Jest atrybut to jest i koniec kropka - niezależnie jaką ma wartość.Dariusz Półtorak edytował(a) ten post dnia 16.12.11 o godzinie 13:42
Wojciech Soczyński

Wojciech Soczyński Programista
eksplorator -
blog.wsoczynski.pl

Temat: OOP - te same pole kilku obiektów

Dariusz Półtorak:
Wojciech Soczyński:
Tak na szybko ;)

Tak z ciekawości (bo przykład podobny do tego który opisałem wyżej) to jak Wam się widzą takie rozwiązania ? Tzn wbudowanie w obiekt czegoś co jest potrzebne tylko w tym konkretnym wypadku i właściwie z samym obiektem nie ma nic wspólnego (mam nadzieje że rozumiecie o co mi chodzi).

Taki rejestr ma tą przewagę że dorzucić możemy referencję dowolnego obiektu i masowo wyciągać z nich możemy co chcemy. Należy zauważyć że chcąc wyciągać jeszcze jakieś dane musimy rozszerzać WSZYSTKIE klasy które będą daną rzecz powielały (jak np ten komunikat błędu) gdzie w innym wypadku poszerzamy taki rejestr obiektów o nowe możliwości współpracy z nimi.

Więc ? Co myślicie ?

Ja myślę, że nasze przykłady różnią się fundamentalnie. W moim przykładzie wykorzystuje wzorzec fabryki i "metody klasy", a więc wszystko co się tyczy errorów mam w jednej klasie. W twoim przykładzie delegujesz część odpowiedzialności do innej klasy w związku z tym rozpraszasz ją po systemie, co może (ale nie musi spowodować "WTF"). Zaletą twojego kodu jest natomiast to, że nie masz statycznych metod, przez co wszystkie zależności są od razu widoczne.

Generalnie myślę, że obu rozwiązaniom daleko od ideału i generalnie uważam, że lepiej by się było zastanowić jaki jest tak naprawdę cel takiego rozwiązania (poznać motywację autora wątku).

konto usunięte

Temat: OOP - te same pole kilku obiektów

Wojciech Soczyński:
Dariusz Półtorak:
Wojciech Soczyński:
Tak na szybko ;)

Tak z ciekawości (bo przykład podobny do tego który opisałem wyżej) to jak Wam się widzą takie rozwiązania ? Tzn wbudowanie w obiekt czegoś co jest potrzebne tylko w tym konkretnym wypadku i właściwie z samym obiektem nie ma nic wspólnego (mam nadzieje że rozumiecie o co mi chodzi).

Taki rejestr ma tą przewagę że dorzucić możemy referencję dowolnego obiektu i masowo wyciągać z nich możemy co chcemy. Należy zauważyć że chcąc wyciągać jeszcze jakieś dane musimy rozszerzać WSZYSTKIE klasy które będą daną rzecz powielały (jak np ten komunikat błędu) gdzie w innym wypadku poszerzamy taki rejestr obiektów o nowe możliwości współpracy z nimi.

Więc ? Co myślicie ?

Ja myślę, że nasze przykłady różnią się fundamentalnie. W moim przykładzie wykorzystuje wzorzec fabryki i "metody klasy", a więc wszystko co się tyczy errorów mam w jednej klasie. W twoim przykładzie delegujesz część odpowiedzialności do innej klasy w związku z tym rozpraszasz ją po systemie, co może (ale nie musi spowodować "WTF"). Zaletą twojego kodu jest natomiast to, że nie masz statycznych metod, przez co wszystkie zależności są od razu widoczne.

Generalnie myślę, że obu rozwiązaniom daleko od ideału i generalnie uważam, że lepiej by się było zastanowić jaki jest tak naprawdę cel takiego rozwiązania (poznać motywację autora wątku).

No tu się nie zgodzę. Zauważ że machanizm pozostaje w obiekcie. Inny jednak zajmuje się wyciąganiem z nich errorów.
Dam Ci lepszy przykład na WTF :P Ktoś wpadnie na pomysł że jednak wyciągając błędy chcieli byśmy je z konkretnych grup obiektów. I zaczynają się schody gdzie taki rejestr rozwiązuje sprawę. Albo dobudowujemy mu gropowanie albo rejestrujemy grupy do osobnych rejestrów. Ogólnie co komu pasuje.

Następna dyskusja:

OOP - Tworzenie nowych obie...




Wyślij zaproszenie do