Co jest nie tak z dziedziczeniem Square i Rectangle?

Question

Przeczytałem kilka artykułów na temat praktyki, która sprawia, że ​​klasa Square klasy dziedziczenia klasy Rectangle jest złą praktyką, mówiąc, że narusza ona LSP (zasada Liskov). Wciąż go nie rozumiem, zrobiłem przykładowy kod w Ruby:

class Rectangle 
    attr_accessor :width, :height 
    def initialize(width, height) 
     @width = width 
     @height = height 
    end 
end 

class Square < Rectangle 
    def initialize(length) 
     super(length, length) 
    end 
    def width=(number) 
     super(number) 
     @height = number 
    end 

    def height=(number) 
     super(number) 
     @width = number 
    end 
end 


s = Square.new(100) 

s.width = 50 

puts s.height 

Czy ktoś mógłby mi powiedzieć, co jest z nim nie tak?

Answer 1

Nie zawsze lubię Liskov, ponieważ wydaje się ograniczać to, co można zrobić z dziedziczeniem w oparciu o zachowanie, a nie "esencję". Moim zdaniem dziedziczenie zawsze miało być relacją "jest", a nie "działa dokładnie tak jak".

Mimo, że the wikipedia article idzie w szczegóły co do dlaczego jest to uważane za złe przez niektóre, używając dokładnie przykład:

Typowym przykładem, który jest niezgodny LSP jest kwadratem klasa, która wywodzi się z prostokąta class, przy założeniu, że istnieją metody getter i setter zarówno dla szerokości, jak i wysokości.

Klasa kwadratowa zawsze zakłada, że ​​szerokość jest równa wysokości. Jeśli obiekt kwadratowy jest używany w kontekście, w którym spodziewany jest prostokąt, może wystąpić nieoczekiwane zachowanie, ponieważ wymiary kwadratu nie mogą (lub raczej nie powinny) być modyfikowane niezależnie.

Ten problem nie może być łatwo naprawiony: jeśli możemy zmodyfikować metody setera w klasie Square, aby zachować niezmienny kwadrat (tj. Zachować wymiary równe), wówczas te metody osłabią (naruszą) warunki dla Ustawniki prostokąta, które określają, że wymiary można modyfikować niezależnie.

Więc patrząc na kodzie obok równoważny kod Rectangle:

s = Square.new(100)   r = Rectangle.new(100,100) 
s.width = 50     r.width = 50 
puts s.height     puts r.height 

wyjście byłoby 50 po lewej stronie i 100 po prawej stronie.

Ale ten jest ważne nieco z artykułu, moim zdaniem:

Naruszenia LSP, jak ten, może lub nie być problemem w praktyce, w zależności od warunki końcowe lub niezmienniki, których rzeczywiście oczekuje kod, który używa klas naruszających LSP.

Innymi słowy, pod warunkiem kod korzystając klas rozumie zachowanie, nie ma problemu.

Konkluzja, kwadrat jest właściwym podzbiorem prostokąta, o luźno na tyle definicji prostokąta :-)

Answer 2

Co jest złego w tym z zasady substytucji Liskov (LSP) perspektywa jest, że Rectangle s i Square s są zmienne. Oznacza to, że musisz jawnie ponownie wprowadzić settery w podklasę i stracić korzyści z dziedziczenia. Jeśli utworzysz Rectangle s niezmienny, tj. Jeśli chcesz inny Rectangle tworzysz nowy, a nie zmieniając pomiarów istniejącego, to nie ma problemu z naruszeniem LSP.

class Rectangle 
    attr_reader :width, :height 

    def initialize(width, height) 
    @width = width 
    @height = height 
    end 

    def area 
    @width * @height 
    end 
end 

class Square < Rectangle 
    def initialize(length) 
    super(length, length) 
    end 
end 

Korzystanie attr_reader daje pobierające ale nie ustawiaczy, stąd niezmienność. Dzięki tej implementacji zarówno Rectangles jak i Squares zapewniają widoczność dla height i width, dla kwadratu, który zawsze będzie taki sam, a pojęcie obszaru jest spójne.

Answer 3

Rozważ abstrakcyjną klasę bazową lub interfejs (niezależnie od tego, czy coś jest interfejsem, czy też klasa abstrakcyjna jest szczegółem implementacji, raczej nieistotnym dla LSP) ReadableRectangle; ma właściwości tylko do odczytu Width i Height. Można by na tej podstawie wyprowadzić typ ReadableSquare, który ma takie same właściwości, ale na mocy umowy gwarantuje, że Width i Height będzie zawsze taki sam.

Z ReadableRectangle, można określić konkretny typ ImmutableRectangle (co zajmuje wysokość i szerokość w konstruktora i gwarantuje, że Height i Width właściwości zawsze zwraca same wartości) i MutableRectangle. Można również zdefiniować typ betonu MutableRectangle, który pozwala ustawić wysokość i szerokość w dowolnym momencie.

Po "kwadratowej" stronie, ImmutableSquare powinien być substytutem zarówno dla ImmutableRectangle, jak i ReadableSquare. Argument MutableSquare można jednak zamienić tylko na ReadableSquare [który z kolei można zamienić na ReadableRectangle.] Ponadto zachowanie ImmutableSquare można zastąpić wartością ImmutableRectangle, dlatego wartość uzyskana w wyniku dziedziczenia konkretnego typu ImmutableRectangle będzie ograniczona. Jeśli ImmutableRectangle byłby abstrakcyjnym typem lub interfejsem, klasa ImmutableSquare potrzebowałaby tylko jednego pola zamiast dwóch do przechowywania jego wymiarów (dla klasy z dwoma polami, zapisywanie nie jest wielkim problemem, ale nie jest trudno wyobrazić sobie zajęcia z dużo więcej pól, gdzie oszczędności mogą być znaczące). Jeśli jednak ImmutableRectangle jest typem konkretnym, wówczas każdy typ pochodny musiałby mieć wszystkie pola swojej podstawy.

Niektóre rodzaje kwadratów można zastąpić odpowiednimi typami prostokątów, ale zmienny kwadrat nie może być zastąpiony zmiennym prostokątem.