Strict Standards Opcje

[likemandrake]

Witam

Mam taki mini problem, mam o to taki zestaw klas:

[PHP] pobierz, plaintext 
<?php
class A {
   // Zestaw metod
}
 
class B extends A {
   // Dodatkowy zestaw metod
}
 
abstract class C {
   public function setObject(A $object) {
      
   }
}
 
abstract class D extends class C {
   public function setObject(B $object) {
      
   }
}
 
class Concrete extends class D {
 
}
?>
[PHP] pobierz, plaintext 

Gdy działam na obiekcie klasy Concrete, php wywala mi taki komunikat:

Strict Standards: Declaration of D::setObject() should be compatible with that of C::setObject() in [...]

Co o tym myślicie, czy nie jest to troszkę na wyrost? Wiadomo, co chciałem przez to osiągnąć... Jak do tego podejść tak w ogóle?

Pozdrawiam

Ten post edytował likemandrake 3.02.2009, 19:46:48

[ayeo]

Nie rozumiem pytania. Co jest na wyrost? Od tego są klasy abstrakcyjne, żeby je potem rozszerzać w klasach potomnych. I tyle. Jak deklarujesz metodę w funkcji abstrakcyjnej to klasa dziedzicząca musi implementować tą metodę. Tak to działa.

Pozdrawiam!

[230005]

Zdaje się, że obie metody setObject() powinny przyjmować jako argument ten sam typ, a u ciebie to A i B :]

[likemandrake]

Dokładnie wiem jak to działa Proszę zwrócić uwagę na deklarację metody setObject klasy C i D i zaznaczam, że nie są to metody abstrakcyjne. Rozumiem, jakby metoda setObject w klasie C została zadeklarowana jako abstrakcyjna, to PHP mógłby rzeczywiście u mnie wymagać 100% kompatybilności, a tak to są zwykłe metody, tyle że w klasach abstrakcyjnych.

Zdaje się, że obie metody setObject() powinny przyjmować jako argument ten sam typ, a u ciebie to A i B :]

No właśnie, PHP mi nakazuje aby te metody były ze sobą kompatybilne, mimo tego, że nie są to metody abstrakcyjne. Stąd moje pytanie, jak do tego podejść.

Po za tym jak widać klasa B dziedziczy po klasie A....

[ayeo]

Witam!

Faktycznie moje niedopatrzenie. Wygląda to na błąd PHP w sumie. Dziwna sprawa

Pozdrawiam!

[likemandrake]

Ściągnąłem ograniczenie abstract z klasy C i D i komunikat pojawia się nadal. Dopiero, gdy w metodzie D::setObject() zmienię przyjmowany parametr na A, PHP nie warczy, a tego nie mogę tak zrobić.

Wniosek z tego taki, że PHP w wersji 5.2.6 ma taki specyficzny błąd.

Czy mógłby ktoś przetestować taki zestaw klas w PHP 5.2.8?
Zaznaczam, że przed wczytaniem pliku z zestawem klas z powyższego kodu musimy ustawić raportowanie błędów na 'E_ALL | E_STRICT'.

[dr_bonzo]

No właśnie, PHP mi nakazuje aby te metody były ze sobą kompatybilne, mimo tego, że nie są to metody abstrakcyjne. Stąd moje pytanie, jak do tego podejść.

W php nie ma przeciazania metod (ta sama nazwa a inne parametry) - wiec nadpisujesz metode w podklasie (zmieniasz jej implementacje), a wiec musza miec te same paramery.

Skoro ja nadpisujesz to musisz zachowac jej sygnature - typ parametru (skoro go specyfikujesz), czemu?
Z definicji OOP:

[PHP] pobierz, plaintext 
<?php
$c = new Concrete_C(); // extends C
$c->setObject( new A() ); // OK
?>
[PHP] pobierz, plaintext 

Tworzysz sobie obiekt typu C (czyli klasy C lub pochodnych == klasy C, D, Concrete, whatever).
Zgodnie z polimorfizmem mozesz wymienic obiekt na inna podklase klasy C, i powinienes miec mozliwosc wykonywania na nim tych samych operacji,
tu: przekazania obiektu klasy A do metody setObject(), ale

[PHP] pobierz, plaintext 
<?php
$c = new Concrete_D(); // extends D
$c->setObject( new A() ); // !!! NIE ZADZIALA, bo A nie jest B (dziedziczenie to relacja odwrotna, B jest A)
?>
[PHP] pobierz, plaintext 

Wiem ze PHP to nie Java/C# i ze jest dynamicznym jezykiem, ale po co w takim razie korzystasz z type-hintingu skoro nie chcesz sie do jego zasad dostosowac?

[PHP] pobierz, plaintext 
<?php
// phph 5.2.6
error_reporting( E_ALL | E_STRICT );
 
class A {
    var $x = 3;
  // Zestaw metod
  protected $object = null;
}
 
class B extends A {
  // Dodatkowy zestaw metod
}
 
abstract class C {
  public function setObject(A $object) {
     $this->object = $object;
  }
}
 
abstract class D extends C {
  public function setObject(B $object) {
     $this->object = $object;     
  }
}
 
class Concrete extends D {
 
}
class Concrete_D extends  D {
 
}
class Concrete_C extends C {
 
}
 
$c = new Concrete_C();
$c->setObject( new A() );
 
print_r( $c );
 
$c = new Concrete_D();
$c->setObject( new B() );  // przyjmuje tylko B
$c->setObject( new A() );  // z A nie zadziala
 
print_r( $c );
?>
[PHP] pobierz, plaintext 

// pomógł++
// ayeo

[likemandrake]

Programowałem w C++ i rzeczywiście jeśliby klasy które napisałem powyżej przestawić na ten język, klasa D zawierałaby dwie wersje metod (taką która przyjmuje obiekty klasy A, oraz taką która przyjmuje obiekty klasy B ).

To by wszystko wyjaśniało, dlaczego tak się dzieje w PHP, możnaby sobie powiedzieć, że z powodu braku funkcji przeładowywania metod, programiści mogliby rozwiązać ten problem inaczej

Cóż najlepszym w takim wypadku będzie w metodzie klasy D przyjmować parametr typu A, oraz rzucać wyjątek w metodzie, jeśli nie przekazano obiektu klasy B.

Pozdrawiam

Ten post edytował likemandrake 3.02.2009, 21:37:19

[Crozin]

A czy przypadkiem klasy A i B nie mogłby implementować jakiegoś interfaceu, a metoda setObject mieć sygnaturę public setObject(myInterface)? Chyba, że te dwa obiekty mają robić coś zupełnie innego, ale wtedy możnaby zacząć się zastanawiać czy aby napewno to co robisz jest poprawne?

[likemandrake]

Tak, mam interfejs, po którym dziedziczy podana wyżej klasa C.

Klasa A, jest to klasa z pakietu Zend Framework, klasa B jest moją klasą, która rozszerza o pare dodatkowych funkcji klasę A.

Znów klasa D dziedziczy po klasie C, ale w porównaniu do klasy C, klasa D korzysta z dodatkowych funkcji nadanych w klasie B.

Efekt jest taki, że klasa, która tu w ogóle nie jest opisana, wymagająca w/w interfejsu, dostaje to co chce i w taki sposób jak powinna. Dane na których wspomniana nieopisana klasa operuje są przygotowane w lepszy sposób przy użyciu zestawu D i B, niż gwarantowałby mi to zestaw C i A.

Pozdrawiam