Odpowiedź na pytanie.
Przed wersją Python 2.3, rozwiązywanie metod opierało się na przeszukiwaniu w głąb, od lewej do prawej, co prowadziło do niespójnych wyników w wzorcach dziedziczenia diamentowego. Algorytm liniaryzacji C3, pierwotnie opracowany dla języka programowania Dylan, został przyjęty w celu zastąpienia tego podejścia. Zapewnia on matematycznie rygorystyczne porządkowanie, które respektuje zarówno graf dziedziczenia, jak i kolejność deklaracji klas bazowych.
W scenariuszach wielokrotnego dziedziczenia wymagamy deterministycznej liniaryzacji, w której rodzice zawsze poprzedzają swoje dzieci, a kolejność deklaracji od lewej do prawej jest zachowana na wszystkich poziomach. Algorytm musi również zachować monotoniczność, co oznacza, że jeśli klasa A poprzedza klasę B w MRO rodzica, to to porządku nie można odwrócić w żadnej podklasie. Niektóre deklaracje dziedziczenia tworzą sprzeczności logiczne, w których te ograniczenia się konfliktują, co uniemożliwia poprawną liniaryzację.
C3 oblicza MRO poprzez scalanie liniaryzacji wszystkich klas rodziców z listą samych rodziców. Algorytm rekurencyjnie wybiera pierwszy element z tych list, który nie pojawia się w ogonie żadnej innej listy, zapewniając, że żadna klasa nie jest umieszczona przed swoimi wymaganiami. Jeśli na którymkolwiek etapie nie istnieje ważny element, Python zgłasza TypeError, wskazując na niespójny porządek rozwiązywania metod.
class A: pass class B(A): pass class C(A): pass class D(B, C): pass # D.__mro__ obliczone jako: merge(L(B), L(C), [B, C]) # Wynik: (<class 'D'>, <class 'B'>, <class 'C'>, <class 'A'>, <class 'object'>) print(D.__mro__)
Sytuacja z życia
Projektowaliśmy framework do przetwarzania danych z użyciem klas mixin, aby dodać aspekty przekrojowe, takie jak logowanie i walidacja. Nasza klasa bazowa DataProcessor zapewniała podstawową funkcjonalność, podczas gdy LoggingMixin i CacheMixin dziedziczyły od BaseComponent dla wspólnych użyteczności. Kiedy klasy konkretne łączyły te mixiny, napotkaliśmy błędy związane z kolejnością inicjalizacji, gdzie buforowanie odbywało się przed logowaniem, a metody BaseComponent były rozwiązywane niespójnie w różnych konkretnych implementacjach.
Pierwszym rozważanym rozwiązaniem było ręczne łączenie metod w każdej klasie konkretnej, wyraźne wywoływanie LoggingMixin.process(), a następnie CacheMixin.process() w twardo zakodowanej sekwencji. To podejście zapewniało wyraźną kontrolę nad kolejnością wykonywania i eliminowało niepewność MRO. Jednak naruszało zasadę DRY, rozsiewając wiedzę o zależnościach po całym kodzie, tworzyło koszmary utrzymaniowe, gdy trzeba było zmienić porządek i łamało polimorfizm, omijając system dynamicznego wywołania.
Drugie podejście polegało na użyciu jawnych wywołań super(LoggingMixin, self) z nazwanymi klasami, zamiast wywołań bezargumentowych super(). To pozwoliło na precyzyjną kontrolę nad tym, która klasa rodzica była następna w łańcuchu rozwiązania, niezależnie od MRO. Choć to działało, było wyjątkowo kruche, ponieważ zmiana nazw klas wymagała aktualizacji każdego wywołania super(), a całkowicie zniweczyło automatyczną liniaryzację Python, czyniąc kod niekompatybilnym z przyszłymi dodatkami mixin bez szerokiej refaktoryzacji.
Trzecie podejście objęło liniaryzację C3, deklarując dziedziczenie jako class Pipeline(LoggingMixin, CacheMixin, DataProcessor) i wdrażając współpracujące wielokrotne dziedziczenie, gdzie każdy init mixina wywoływał super().init(). To pozwoliło MRO naturalnie określić, że LoggingMixin poprzedza CacheMixin, pozostawiając DataProcessor na końcu. To rozwiązanie respektowało semantykę dziedziczenia Python, nie wymagało żadnych twardo zakodowanych odniesień do klas i pozwalało na automatyczne dostosowanie frameworku do nowych mixinów poprzez proste aktualizowanie nagłówka klasy.
Wybraliśmy trzecie rozwiązanie, ponieważ było zgodne z filozofią projektowania Python, a nie walczyło z nią. Wykorzystując wywołanie bezargumentowe super(), każdy mixin mógł przekazać kontrolę nad inicjalizacją do następnej klasy w MRO, nie wiedząc, czym ta klasa była, co umożliwiało prawdziwą kompozycyjność. Wyraźne porządkowanie w deklaracji klasy sprawiło, że relacja priorytetów była widoczna i łatwa do utrzymania.
Wynikiem był solidny framework wspierający ponad trzydzieści wariantów procesora z różnymi kombinacjami mixinów. Programiści mogli tworzyć nowe typy potoków deklaratywnie, bez obaw o błędy związane z kolejnością inicjalizacji. C3 zapobiegał błędom architektonicznym, zgłaszając TypeError w czasie definicji klasy, gdy programiści próbowali stworzyć niespójne wzorce dziedziczenia, wychwytując sprzeczności logiczne w trakcie rozwoju, a nie w produkcji.
Co często umykają kandydatom
Dlaczego algorytm liniaryzacji C3 w Python odrzuca niektóre hierarchie wielokrotnego dziedziczenia z błędem „Nie można stworzyć spójnego porządku rozwiązywania metod”, i jak można to rozwiązać bez modyfikowania fundamentalnych wymagań dziedziczenia?
Algorytm odrzuca hierarchie, gdy ograniczenia dotyczące priorytetu tworzą sprzeczność logiczną, której żadna liniaryzacja nie może zaspokoić. Dzieje się tak, gdy jeden rodzic wymaga, aby klasa X poprzedzała klasę Y, podczas gdy inny rodzic wymaga, aby Y poprzedzała X, tworząc cykl, którego nie można rozwiązać. Aby to naprawić bez usuwania potrzebnych relacji, należy przerobić użycie kompozycji zamiast dziedziczenia dla jednej z konfliktujących gałęzi lub wyodrębnić wspólną funkcjonalność do współdzielonej klasy bazowej, z której obaj rodzice dziedziczą, tym samym przerywając cykl priorytetów przy zachowaniu interfejsu.
Jak Python's zero-argument super() faktycznie określa, którą klasę przeszukać następnie w MRO podczas użycia wewnątrz metody, i dlaczego różni się to od jawnego super(CurrentClass, self) w złożonych grafach dziedziczenia?
Zero-argumentowe super() używa zmiennej komórkowej class (przechwyconej przez definicję metody) oraz mro instancji, aby dynamicznie znaleźć następną klasę w czasie wykonywania. Lokalizuje bieżącą klasę w MRO, a następnie zwraca proxy dla następnej klasy. To różni się od jawnego super(CurrentClass, self), które statycznie określa punkt początkowy; jeśli metoda jest dziedziczona przez podklasę, forma jawna wciąż rozpoczyna od CurrentClass, co może pominąć klasy w rzeczywistym MRO podklasy, podczas gdy zero-argumentowe super() automatycznie dostosowuje się, aby kontynuować od klasy definiującej metodę w hierarchii bieżącej instancji.
Jaka jest cecha monotoniczności w liniaryzacji C3, i dlaczego jest kluczowa dla utrzymania przewidywalnego zachowania podczas dziedziczenia istniejących hierarchii wielokrotnego dziedziczenia?
Monotoniczność gwarantuje, że jeśli klasa A poprzedza klasę B w MRO klasy rodzica, A zawsze będzie poprzedzać B we wszystkich podklasach tego rodzica. Zapobiega to błędowi „przesunięcia cieniującego” występującemu w starszych algorytmach przeszukiwania w głąb, gdzie dodanie podklasy mogłoby niespodziewanie odwrócić priorytet dwóch niepowiązanych klas rodziców. Bez tej właściwości, dodanie nowego mixina do klasy mogłoby zmienić względne uporządkowanie istniejących rodziców, powodując, że metody byłyby wykonywane w różnych sekwencjach w klasach rodziców w porównaniu do klas dzieci, prowadząc do subtelnych regresji behawioralnych w dużych drzewach dziedziczenia.