Czy zasada podstawienia Liskowa jest niezgodna z introspekcją lub pisaniem kaczek?

Czy rozumiem poprawnie, że nie można przestrzegać zasady substytucji Liskowa w językach, w których obiekty mogą się sprawdzać, tak jak w przypadku języków pisanych kaczorkiem?

Na przykład, w Ruby, jeśli klasa Bdziedziczy z klasy A, a następnie za każdy przedmiot xz A, x.classjedzie do powrotu A, ale jeśli xjest przedmiotem B, x.classnie ma powrotu A.

Oto oświadczenie LSP:

Niech q (x) być właściwością dowodliwe o obiekty x typu T . Następnie Q (y) powinny być udowodnione dla obiektów Y typu S , gdzie S jest podtypem T .

Na przykład w Ruby

class T; end
class S < T; end

naruszają LSP w tej formie, o czym świadczy właściwość q (x) =x.class.name == 'T'

Dodanie. Jeśli odpowiedź brzmi „tak” (LSP niezgodny z introspekcją), moje inne pytanie brzmiałoby: czy istnieje jakaś zmodyfikowana „słaba” forma LSP, która może być w stanie utrzymać dynamiczny język, być może pod pewnymi dodatkowymi warunkami i tylko ze specjalnymi typami o właściwościach .

Aktualizacja. Dla porównania, oto inne sformułowanie LSP, które znalazłem w sieci:

Funkcje korzystające ze wskaźników lub referencji do klas podstawowych muszą mieć możliwość korzystania z obiektów klas pochodnych bez ich znajomości.

I kolejny:

Jeśli S jest zadeklarowanym podtypem T, obiekty typu S powinny zachowywać się tak, jak obiekty typu T powinny się zachowywać, jeśli są traktowane jako obiekty typu T.

Ostatni jest opatrzony adnotacjami:

Zauważ, że LSP dotyczy oczekiwanego zachowania obiektów. Można śledzić LSP tylko wtedy, gdy jest jasne, jakie jest oczekiwane zachowanie obiektów.

Wydaje się, że jest to słabsze niż pierwotne i może być możliwe do zaobserwowania, ale chciałbym, aby było to sformalizowane, w szczególności wyjaśnione, kto decyduje o oczekiwanym zachowaniu.

Czy zatem LSP nie jest własnością pary klas w języku programowania, ale pary klas wraz z danym zestawem właściwości, spełnianych przez klasę przodka? Czy w praktyce oznacza to, że aby skonstruować podklasę (klasę potomną) w odniesieniu do LSP, wszystkie możliwe zastosowania klasy przodka muszą być znane? Według LSP klasa przodków ma być zastępowalna dowolną klasą potomną, prawda?

Aktualizacja. Przyjąłem już odpowiedź, ale chciałbym dodać jeszcze jeden konkretny przykład od Ruby, aby zilustrować pytanie. W Ruby każda klasa jest modułem w tym sensie, że Classklasa jest potomkiem Moduleklasy. Jednak:

class C; end
C.is_a?(Module) # => true
C.class # => Class
Class.superclass # => Module

module M; end
M.class # => Module

o = Object.new

o.extend(M) # ok
o.extend(C) # => TypeError: wrong argument type Class (expected Module)

Oto faktyczna zasada :

Pozwól q(x)być właściwością dającą się udowodnić o obiektach xtypu T. Następnie q(y)należy udowodnić dla obiektów ytypu Sgdzie Sjest podtypem T.

I doskonałe streszczenie Wikipedii :

Stwierdza się, że w programie komputerowym, jeśli S jest podtypem T, wówczas obiekty typu T można zastąpić obiektami typu S (tj. Obiekty typu S można zastąpić obiektami typu T) bez zmiany żadnego z pożądane właściwości tego programu (poprawność, wykonane zadanie itp.).

I kilka istotnych cytatów z artykułu:

Potrzebny jest silniejszy wymóg, który ogranicza zachowanie podtypów: właściwości, które można udowodnić za pomocą specyfikacji domniemanego typu obiektu, powinny zostać zachowane, nawet jeśli obiekt faktycznie jest członkiem podtypu tego typu ...

Specyfikacja typu zawiera następujące informacje:
- nazwę typu;
- Opis przestrzeni wartości typu;
- Dla każdej z metod tego typu:
--- Jego nazwa;
--- Jego podpis (w tym sygnalizowane wyjątki);
--- Jego zachowanie w zakresie warunków wstępnych i dodatkowych.

Przejdźmy do pytania:

Czy rozumiem poprawnie, że nie można przestrzegać zasady substytucji Liskowa w językach, w których obiekty mogą się sprawdzać, tak jak w przypadku języków pisanych kaczorkiem?

Nie.

A.classzwraca klasę.
B.classzwraca klasę.

Ponieważ możesz wykonać to samo połączenie na bardziej konkretnym typie i uzyskać zgodny wynik, LSP wstrzymuje. Problem polega na tym, że w przypadku dynamicznych języków nadal można wywoływać różne wyniki, oczekując, że będą dostępne.

Ale zastanówmy się nad statycznym, strukturalnym językiem (kaczym). W takim przypadku A.classzwróci typ z ograniczeniem, które musi być, Alub podtypem A. Daje to statyczną gwarancję, że każdy podtyp Amusi zapewniać metodę, T.classktórej wynikiem jest typ spełniający to ograniczenie.

Zapewnia to silniejsze twierdzenie, że LSP utrzymuje się w językach, które obsługują pisanie kaczek, i że każde naruszenie LSP w czymś takim jak Ruby występuje częściej z powodu normalnego niewłaściwego użycia dynamicznego niż niezgodności projektu językowego.

W kontekście LSP „właściwość” to coś, co można zaobserwować na typie (lub obiekcie). W szczególności mówi się o „własności do udowodnienia”.

Taka „właściwość” mogłaby istnieć w przypadku foo()metody, która nie ma wartości zwrotnej (i jest zgodna z umową określoną w jej dokumentacji).

Upewnij się, że nie pomylisz tego terminu z „właściwość”, ponieważ „ classjest własnością każdego obiektu w Rubim”. Taka „właściwość” może być „właściwością LSP”, ale nie jest automatycznie taka sama!

Teraz odpowiedź na twoje pytania zależy w dużej mierze od tego, jak surowo zdefiniujesz „właściwość”. Jeśli powiesz „własność klasy Ajest to, że .classpowróci typ obiektu”, wtedy Brzeczywiście nie mają tę właściwość.

Jeśli jednak zdefiniować „własność” być „ .classpowraca A”, to oczywiście Bnie nie posiadają tę właściwość.

Jednak druga definicja nie jest zbyt przydatna, ponieważ zasadniczo znalazłeś okrągły sposób na zadeklarowanie stałej.

Jak rozumiem, w introspekcji nie ma nic, co byłoby niezgodne z LSP. Zasadniczo, o ile obiekt obsługuje te same metody co inne, oba powinny być wymienne. Oznacza to, że jeśli kod oczekuje Addressobiekt, to nie ma znaczenia, czy jest to CustomerAddresslub WarehouseAddress, o ile oba dostarczają (na przykład) getStreetAddress(), getCityName(), getRegion()i getPostalCode(). Z pewnością możesz stworzyć dekorator, który pobiera inny typ obiektu i wykorzystuje introspekcję, aby zapewnić wymagane metody (np. DestinationAddressKlasa, która przyjmuje Shipmentobiekt i przedstawia adres dostawy jako Address), ale nie jest to wymagane i na pewno nie zapobiegają stosowaniu LSP.

Po przejrzeniu oryginalnej pracy Barbary Liskov odkryłem, jak uzupełnić definicję Wikipedii, aby LSP rzeczywiście był zadowolony w prawie każdym języku.

Przede wszystkim słowo „możliwe do udowodnienia” jest ważne w definicji. Nie jest to wyjaśnione w artykule na Wikipedii, a „ograniczenia” są wymienione gdzie indziej, bez odniesienia do niego.

Oto pierwszy ważny cytat z artykułu:

Potrzebny jest silniejszy wymóg, który ogranicza zachowanie podtypów: właściwości, które można udowodnić za pomocą specyfikacji domniemanego typu obiektu, powinny zostać zachowane, nawet jeśli obiekt faktycznie jest członkiem podtypu tego typu ...

A oto druga, wyjaśniająca, czym jest specyfikacja typu :

Specyfikacja typu zawiera następujące informacje:

• Nazwa typu;
• Opis przestrzeni wartości typu;
• Dla każdej z metod tego typu:
  • Jego nazwa;
  • Podpis (w tym sygnalizowane wyjątki);
  • Jego zachowanie w zakresie warunków wstępnych i dodatkowych.

Zatem LSP ma sens tylko w odniesieniu do danych specyfikacji danego typu , a dla odpowiedniej specyfikacji typu (na przykład dla pustej) może być spełniony prawdopodobnie w dowolnym języku.

Uważam, że odpowiedź Telastyn jest najbliższa temu, czego szukałem, ponieważ „ograniczenia” zostały wyraźnie wymienione.

Cytując artykuł Wikipedii na temat LSP , „podstawialność jest zasadą w programowaniu obiektowym”. Jest to zasada i część projektu twojego programu. Jeśli piszesz kod, który zależy x.class == A, to twój kod narusza LSP. Uwaga: ten rodzaj zepsutego kodu jest również możliwy w Javie, nie trzeba wpisywać kaczki.

Nic w wpisywaniu kaczek z natury nie łamie LSP. Tylko jeśli użyjesz go niewłaściwie, jak w twoim przykładzie.

Dodatkowa myśl: czy jawne sprawdzanie, czy klasa obiektu nie spełnia celu pisania kaczką?