[OOP]Funkcja z dowolnym parametrem Opcje

[HgReed]

Witam.
Natknąłem się dzisiaj na taki problem. Zobrazuje to na przykładzie.

[PHP] pobierz, plaintext 
abstract class Main {
    abstract function __construct();
}
 
class Dziecko_1 extends Main {
    function __construct($a, $b) {     //Żeby to było możliwe
        echo $a.$b;
    }
}
[PHP] pobierz, plaintext 

Czyli chodzi mi oto - czy klasa dziedzicząca (lub implementująca interfejs) miała dowolny parametr (funkcja musi być 'wymagana')?

[Orzeszekk]

jak wywalisz abstract function __construct(); to stanie sie to mozliwe. Jak masz abstract w klasie rodzica to implementacje tej metody musza miec idealnie te same parametry.

ewentualnie jesli chcesz strasznie zeby w main zostal ten abstract function __construct to mozesz w Dziecko_1 zrobic tak

public function __construct($a=null, $b=null)
{
if ((is_numeric($a) && is_numeric($b))==false) {throw RuntimeException("BŁędne parametry.")}
}
tez nie powinien krzyczec.

[HgReed]

Właśnie mi chodzi o to, żeby ta funkcja X była w abstract'ie - musi być wymagana.
Chyba zostaje mi tylko wklepanie array $array = array() jako parametr i sprawdzanie zawartości :/

[Crozin]

A mógłbyś opisać jaki jest Twój problem? Tj. skąd taki wymóg. Wydaje mi się, że możesz po prostu źle podchodzić do tego już od strony projektowej.

[Orzeszekk]

Właśnie mi chodzi o to, żeby ta funkcja X była w abstract'ie - musi być wymagana.
Chyba zostaje mi tylko wklepanie array $array = array() jako parametr i sprawdzanie zawartości :/

No to tak jak ci napisałem robisz function coś ( $param1=null, $param2=null) w implementacji, a w abstrakcie robisz
abstract function coś (); i działa.

Choc nie jest to rozwiazanie zbyt eleganckie.

Jesli chcesz rozwiazania poprawnego to mozesz jeszcze utworzyc valueObject - tak jak jest np w eventach javascriptu i C#.

nigdy nie ma event handlerów
function eventHandler(eventID, eventName,x, y, .....)

zawsze jest

function eventHandler(eventArgs).

[PHP] pobierz, plaintext 
class PrzodekParameterSet
{
 protected $eventName; 
 public function getEventName() { return $this->eventName; } 
 public function setEventName($value) { $this->eventName = $value; }
 public function __construct($eventName) { $this->setEventName($eventName); }
}
 
abstract class Przodek
{
   abstract public function jakasMetoda(PrzodekParameterSet $parameters);
}
 
class Dziecko extends Przodek
{
   public function jakasMetoda(PrzodekParameterSet $parameters)  { /* tresc */ }
}
 
class DrugieDzieckoParameterSet extends PrzodekParameterSet
{
  protected $dodatkowyParam;
  public function getDodatkowyParam() { return $this->dodatkowyParam; }
  public function setDodatkowyParam($value) { $this->dodatkowyParam = $value;}
  public function __construct($eventName, $dodatkowyParam)
  {
    parent::__construct($eventName);
    $this->setDodatkowyParam($dodatkowyParam);
  }
}
 
class DrugieDziecko extends Przodek
{
   public function jakasMetoda(DrugieDzieckoParameters $parameters)
   {
    }
}
 
 
$dziecko = new Dziecko();
$dziecko->jakasMetoda(new PrzodekParameterSet("nowy_event"));
$drugieDziecko = new DrugieDziecko;
$drugieDziecko->jakasMetoda(new DrugieDzieckoParameterSet("nowy_event", "dodatkowy_param"));
 
[PHP] pobierz, plaintext 

tez powinno chodzic.
Tylko dla mnie definiowanie konstruktora jako abstrakcyjnego jest z deka pozbawione sensu - kazda klasa ma swoj konstruktor (pusty),
i konstruktory w klasach dziedziczacych moga miec rozna liste parametrów.
Natomiast zwykle metody zefiniowane jako abstrakcyjne musza miec taka sama liste parametrów i mozesz to zastosowac.


Nie stosuj tablic (zamiast nich stosuj valueObjecty - to jedna z dobrych praktyk) - po paru miesiacach moze byc problem z odgadnieciem jak ta tablica powinna wygladac. No i w zasadzie nie masz sposobu by wymusic jakis parametr, jezeli jest obowiazkowy.

ja odkad pracuje z php nie mialem powodu by stosowac takie dziwaczne konstrukcje, wiec moze po prostu projekt twoich klas jest blędny i dlatego wymusza takie rozwiazania? moze jego poprawienie rozwiaze problem w prostszy sposob tak jak pisze crozin

Ten post edytował Orzeszekk 26.02.2012, 18:01:22

[HgReed]

Te valueObject'y to - jak dla mnie - przerost formy nad treścią.

A temat rozwiązany - "wystarczyło" dopisać sobie 3 funkcje i idzie to obejść.

PS. Ten __construct był tylko przykładem, a nie moim problemem.

[Orzeszekk]

Te valueObject'y to - jak dla mnie - przerost formy nad treścią.

Tak ci sie tylko wydaje (IMG:style_emoticons/default/smile.gif)

wygenerowanie takiego value objectu w porządnym ide to kilka sekund, a po paru miesiacach pozwalają się połapać o co chodziło.
dobrą praktyką jest zamiana tablic na value objecty w takich sytuacjach.

Wolalbys dostac takie eventArgs jako value object, ładnie podpisane np eventArgs klikniecia myszki: x,y- wspolrzedne, buttonPress- jaki przycisk zostal wcisniety itd itd, czy wolalbys dostac tablicę 20 wartosci w nieznanej kolejnosci i bobrowac dokumentacje który jest który?(IMG:style_emoticons/default/tongue.gif)
A moze ktorys z parametrow to kilkukrotnie zagniezdzona tablica? Hmm.. ile razy ona zagniezdzona byla i co było czym... sytuacje z zycia wziete ;P+dolicz troche czasu na debugowanie przez pomyłki

Mądry autor ksiażki "clean Code" zaleca zamiane tablic na value objecty, zaleca by w tych value objectach nie robic publicznych pól, tylko dostęp do nich był przez gettery/settery i zaleca uzywac getterow/setterow nawet wewnatrz klasy zamiast bezposredniego dostępu do wartosci, i ja sie go słucham bo wiele jego teorii sie sprawdzilo w praktyce. Niewielkim kosztem wydajności która w PHP i tak jest do dupy, uzyskujesz duzo bardziej idiotoodporny kod.

Ten post edytował Orzeszekk 26.02.2012, 22:28:44