Dlaczego przesłanianie parametrów metody stanowi naruszenie ścisłych standardów w PHP?

Question

Wiem, że istnieje kilka podobnych pytań tutaj w StackOverflow, takich jak this question.

Dlaczego przesłanianie parametrów metody stanowi naruszenie ścisłych standardów w PHP? Na przykład:

class Foo 
{ 
    public function bar(Array $bar){} 
} 

class Baz extends Foo 
{ 
    public function bar($bar) {} 
} 

surowe normy: Deklaracja Baz :: bar() powinny być zgodne z że Foo :: Bar()

w innych językach programowania OOP można . Dlaczego jest źle w PHP?

Answer 1

W OOP, SOLID oznacza jednolitego odpowiedzialność, Open-zamknięte , Podstawienie Liskov, segregacja interfejsu i inwersja zależności:.

Liskov substitution zasada stwierdza, że ​​w programie komputerowym, jeśli Bar jest podtypem Foo, to obiekty typu Foo można zastąpić obiektów typu Bar bez zmiany któregokolwiek z pożądanych właściwościach tego programu (poprawność, wykonane zadanie itp.).

W językach programowania napisanych silnie na maszynie, po nadpisaniu metody Foo, jeśli zmienisz podpis na pasku, faktycznie jesteś przeciążony przeciążając, ponieważ oryginalna metoda i nowa metoda są dostępne z różnymi sygnaturami. Ponieważ PHP jest słabo napisane, nie można tego osiągnąć, ponieważ kompilator nie może wiedzieć, którą z metod faktycznie wywołuje. (stąd powód, dla którego nie możesz mieć 2 metod o tej samej nazwie, nawet jeśli ich podpisy są różne).

Aby uniknąć naruszenia zasady Liskov Substitution, wydawane jest ostrzeżenie standardowe, informujące programistę, że coś może się zepsuć z powodu zmiany sygnatury metody w klasie potomnej.

Answer 2

Można nadpisać parametry, ale podpis powinien być zgodny. Jeśli odłożyłeś Array przed $bar, nie byłoby problemu.

Na przykład, jeśli dodałeś dodatkowy parametr, nie byłoby problemu, pod warunkiem, że pierwszy parametr miałby ten sam typ podpowiedzi. Jest to dobra praktyka w każdym języku.

Answer 3

Ponieważ zadeklarowane Foo że $bar powinny być typu array, natomiast w rozciągającej Bar, $bar „s typ nie jest zadeklarowana.

To nie jest błąd, to ostrzeżenie. Powinieneś uczynić definicję metody zgodną z oryginalną, podstawową klasą. Można jednak bezpiecznie zignorować, jeśli wiesz co robisz (i tylkojeśli wiesz co robisz !!!)

Answer 4

Wiem, że spóźniam się na imprezę, ale odpowiedzi nie wyjaśniają rzeczywistego problemu.

Problem polega na tym, że PHP nie obsługuje przeciążania funkcji/metod. Trudno byłoby wspierać przeciążanie funkcji w języku bez typu.

Podpowiedź pomaga. ale w PHP jest bardzo ograniczony. Nie pewny dlaczego. Na przykład nie możesz wskazać, że zmienna to int lub Boolean, ale tablica jest w porządku. Domyśl!

Inne języki zorientowane obiektowo realizują to przy użyciu funkcji przeciążania. Co oznacza, że ​​podpis funkcji jest oczywiście inny.

Tak na przykład, jeśli następuje to możliwe, że nie będzie miał problemu

class Foo 
{ 
    public function bar(Array $bar){ 
     echo "Foo::bar"; 
    } 
} 

class Baz extends Foo 
{ 
    public function bar(int $bar) { 
     echo "Baz::bar"; 
    } 
} 


$foo = new Baz(); 
$bar = new Baz(); 
$ar = array(); 
$i = 100; 

$foo->bar($ar); 
$bar->bar((int)$i); 

would output 

Foo::bar 
Baz::bar 

Oczywiście, gdy przyszło do konstruktorów programiści php sobie sprawę, że trzeba go wdrożyć, podoba czy nie! Po prostu tłumią błąd lub nie podnoszą go w pierwszym przypadku.

Co jest głupie.

Kiedyś znajomy PHP zaimplementował obiekty tylko jako sposób implementacji przestrzeni nazw. Teraz nie jestem aż tak krytyczny, ale niektóre z podjętych decyzji mają tendencję do popierania tej teorii.

Zawsze mam włączone maksymalne ostrzeżenia podczas tworzenia kodu, nigdy nie pozwolę, aby ostrzeżenie przeszło bez zrozumienia, co to oznacza i jakie są tego konsekwencje. Osobiście nie obchodzi mnie to ostrzeżenie. Wiem, co chcę zrobić i PHP nie robi tego dobrze. Przyszedłem tutaj, szukając sposobu, aby go selektywnie stłumić. Jeszcze nie znalazłem sposobu.

Więc zatrzymam to ostrzeżenie i stłumię je. Wstyd, muszę to zrobić. ale ja jestem surowy w odniesieniu do STRICT.