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')?

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.

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 :/

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.

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

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.

Tak ci sie tylko wydaje

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?
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.