فصل ششم: ارث‌بری پیشرفته، MRO و وراثت چندگانه

مقدمه

در فصل چهارم با مفهوم بنیادین ارث‌بری آشنا شدیم: کلاسی که از یک کلاس والد مشتق می‌شود. اما پایتون قابلیتی فراتر از این رویکرد ساده ارائه می‌دهد؛ قابلیتی که بسیاری از زبان‌های رایج مانند جاوا عمداً از آن پرهیز می‌کنند: وراثت چندگانه یا امکان ارث‌بری یک کلاس از چندین والد به طور همزمان.

این ویژگی، شمشیری دولبه است. از یک سو، ابزاری بسیار قدرتمند برای طراحی ماژولار و انعطاف‌پذیر در اختیار برنامه‌نویس قرار می‌دهد. از سوی دیگر، اگر بدون درک عمیق و رعایت اصول صحیح به کار گرفته شود، می‌تواند به آشفتگی‌های پیچیده‌ای در کد منجر شود که رهگیری و رفع خطاهای ناشی از آن را به کاری دشوار تبدیل می‌کند. هدف این فصل، توانمندسازی شما برای استفاده‌ی هوشمندانه و ایمن از این قابلیت است.

در مسیر این توانمندسازی، با مفاهیم کلیدی و راهگشایی آشنا خواهید شد: مسئله‌ی الماس (Diamond Problem) که نشان‌دهنده‌ی چالش اصلی وراثت چندگانه است، الگوریتم C3 که پایتون برای حل این مسئله به کار می‌گیرد، و در نهایت Mixinها که به عنوان امن‌ترین و کاربردی‌ترین الگوی استفاده از وراثت چندگانه شناخته می‌شوند.

چرا درک ارث‌بری پیشرفته ضروری است؟

ممکن است در پروژه‌های شخصی و ساده‌ی خود، هرگز نیازی به طراحی سلسله‌مراتب پیچیده‌ای با وراثت چندگانه پیدا نکنید. با این حال، زمانی که با فریم‌ورک‌های قدرتمند و پرکاربردی مانند جنگو (Django) یا DRF (Django REST Framework) کار می‌کنید، به وفور با کلاس‌هایی مواجه می‌شوید که از چندین والد (اغلب به شکل Mixinها) ارث برده‌اند. نادیده گرفتن این مفاهیم، شما را با چالش‌های زیر روبرو می‌کند:

• درک نادرست از نحوه‌ی فراخوانی متدها در زنجیره‌ی پیچیده‌ی ارث‌بری.
• مواجهه با ابهامات و خطاهای ناشی از مسئله‌ی الماس که ریشه‌یابی آنها زمان‌بر خواهد بود.
• از دست دادن فرصت استفاده از Mixinها برای ایجاد کدی ماژولار، خوانا و قابل استفاده‌ی مجدد.
• تبدیل شدن کدهای کتابخانه‌ها و فریم‌ورک‌ها به جعبه‌های سیاهی که تنها از روی عادت از آنها استفاده می‌کنید، بدون درک فلسفه و سازوکار درونی‌شان.

وراثت چندگانه: تعریف و ضرورت

وراثت چندگانه به زبانی ساده یعنی یک کلاس می‌تواند همزمان از دو یا چند کلاس دیگر مشتق شود و تمام ویژگی‌ها و متدهای آن‌ها را به ارث ببرد. پایتون از ابتدا این قابلیت را در طراحی خود گنجانده است.

چرا پایتون این راه را انتخاب کرده است؟

برای پاسخ به این سوال، مقایسه‌ای کوتاه با زبان جاوا مفید است. جاوا به دلیل نگرانی از پیچیدگی‌ها و ابهامات ناشی از وراثت چندگانه (به ویژه مسئله‌ی الماس)، این ویژگی را به طور کامل ممنوع کرده است. در عوض، مفهومی به نام interface را معرفی می‌کند که صرفاً شامل امضای متدها (و نه پیاده‌سازی آن‌ها) است و کلاس‌ها می‌توانند چندین interface را پیاده‌سازی کنند.

اما فلسفه‌ی پایتون متفاوت است. پایتون بر اساس اعتماد به برنامه‌نویس و اصل «همه بزرگسالیم» (We are all consenting adults) بنا شده است. این زبان ابزارهای قدرتمند را در اختیار شما می‌گذارد و مسئولیت استفاده‌ی درست و عاقلانه از آن‌ها را به عهده‌ی خودتان می‌گذارد. به همین دلیل، پایتون وراثت چندگانه را مجاز می‌داند، اما برای جلوگیری از هرج و مرج، یک الگوریتم دقیق و علمی برای حل ابهامات احتمالی تعریف کرده است: الگوریتم C3 که در ادامه به تفصیل به آن خواهیم پرداخت.

بیایید با یک مثال ساده، مفهوم وراثت چندگانه را مشاهده کنیم:

class Serializable:
    def to_json(self):
        import json
        return json.dumps(self.__dict__)

class Comparable:
    def __lt__(self, other):
        return self.value < other.value

class Number(Serializable, Comparable):
    def __init__(self, value):
        self.value = value

n = Number(5)
print(n.to_json())            # {"value": 5}   <- from Serializable
print(Number(3) < Number(7))  # True           <- from Comparable

در این مثال، کلاس Number هیچ متد جدیدی تعریف نکرده است، اما به لطف وراثت چندگانه، هم قابلیت تبدیل به JSON (از Serializable) و هم قابلیت مقایسه‌ی عددی (از Comparable) را دریافت کرده است.

مسئله‌ی الماس (Diamond Problem) و راه‌حل پایتون

بهترین راه برای درک ضرورت الگوریتم C3، بررسی یک سناریوی کلاسیک و چالش‌برانگیز است: مسئله‌ی الماس.

فرض کنید ساختاری از کلاس‌ها داریم که به شکل زیر است (همانند یک الماس):

        A
       / \
      B   C
       \ /
        D

یعنی کلاس D از دو کلاس B و C ارث می‌برد، و هر دو کلاس B و C نیز از یک کلاس مشترک به نام A ارث برده‌اند.

حال سوال اساسی این است: اگر متدی در کلاس A تعریف شده باشد و هر دو کلاس B و C آن را بازنویسی (override) کرده باشند، وقتی یک شیء از کلاس D آن متد را فراخوانی می‌کند، آیا نسخه‌ی B اجرا می‌شود یا نسخه‌ی C؟ چه می‌شود اگر هر دو B و C در متد خود، متد والد را با super() فراخوانی کنند؟ آیا متد A دو بار اجرا می‌شود؟

اجازه دهید با یک مثال عملی این ابهام را بررسی کنیم:

class A:
    def __init__(self):
        print("A")

class B(A):
    def __init__(self):
        print("B")
        super().__init__()

class C(A):
    def __init__(self):
        print("C")
        super().__init__()

class D(B, C):
    def __init__(self):
        print("D")
        super().__init__()

D()
# Output:
# D
# B
# C
# A

نتیجه‌ی اجرا بسیار روشنگر است. اول D، سپس B، سپس C و در نهایت A چاپ می‌شود. دو نکته‌ی حیاتی در این خروجی نهفته است:

1. ترتیب اجرا به صورت D → B → C → A است.
2. کلاس A تنها یک بار اجرا می‌شود، نه دو بار، علیرغم اینکه هر دو کلاس B و C در متد خود، متد A را فراخوانی کرده‌اند.

این «جادو» کار الگوریتم C3 و ترتیب حل متدها (MRO) است که پایتون برای مدیریت وراثت چندگانه به کار می‌گیرد.

MRO (Method Resolution Order) و الگوریتم C3

MRO مخفف عبارت Method Resolution Order است و به زبان ساده، ترتیب دقیقی است که پایتون برای جستجوی یک متد در سلسله‌مراتب کلاس‌ها دنبال می‌کند. زمانی که متدی را روی یک شیء فراخوانی می‌کنید، پایتون به ترتیب MRO در کلاس‌ها جستجو می‌کند تا اولین پیاده‌سازی را پیدا کند.

الگوریتمی که پایتون برای تولید این ترتیب به کار می‌برد، الگوریتم C3 Linearization نام دارد. این الگوریتم با رعایت سه قانون اساسی، یک ترتیب خطی و بی‌ابهام تولید می‌کند:

1. تقدم زیرکلاس بر والد: یک کلاس همواره پیش از والدین خود در ترتیب MRO قرار می‌گیرد.
2. حفظ ترتیب والدین: ترتیبی که والدین در تعریف کلاس ذکر شده‌اند (مثلاً class D(B, C)) در MRO حفظ می‌شود.
3. ظاهر شدن یک‌باره‌ی کلاس‌ها: یک کلاس، صرف‌نظر از تعداد مسیرهایی که از طریق آن به اجداد می‌رسیم، فقط یک بار و در جایگاه صحیح خود در MRO ظاهر می‌شود.

شما می‌توانید MRO هر کلاسی را با استفاده از ویژگی __mro__ یا متد mro() مشاهده کنید. برای مثال الماس بالا، خروجی به این صورت خواهد بود:

print(D.__mro__)
# (<class 'D'>, <class 'B'>, <class 'C'>, <class 'A'>, <class 'object'>)

این دقیقاً ترتیبی است که در خروجی مثال قبل دیدیم. این ترتیب نشان می‌دهد که تابع super() در هر مرحله، به جای اشاره به والد مستقیم (که در B می‌تواند A باشد)، به کلاس بعدی در زنجیره‌ی MRO اشاره می‌کند. به همین دلیل است که در مثال بالا، super().__init__() در کلاس B، کلاس C را صدا می‌زند و نه A را. این مکانیزم هوشمندانه، هم ترتیب اجرای صحیح را تضمین می‌کند و هم از اجرای چندباره‌ی کلاس ریشه (A) جلوگیری می‌نماید.

قاعده‌ی طلایی: در هر جایی که با وراثت چندگانه سروکار دارید، همیشه از super() برای فراخوانی متدهای والد استفاده کنید، نه از نام مستقیم کلاس والد (مثل A.__init__(self)). استفاده از نام مستقیم، زنجیره‌ی هوشمند super() را دور می‌زند و می‌تواند منجر به اجرای چندباره یا از قلم افتادن کلاس‌هایی در زنجیره‌ی MRO شود که رفع خطاهای ناشی از آن بسیار دشوار است.

بررسی عمیق‌تر MRO: گام‌های الگوریتم C3

برای درک بصری‌تر از نحوه‌ی عملکرد الگوریتم C3، بیایید فرآیند تولید MRO را برای ساختار الماس D(B, C) با B(A) و C(A) گام‌به‌گام دنبال کنیم:

1. آغاز از خود کلاس: الگوریتم کار را با خود کلاس D آغاز می‌کند. MRO موقت: [D].
2. بررسی اولین والد (B): طبق قانون «زیرکلاس پیش از والد»، B که والد مستقیم D است، به MRO اضافه می‌شود. MRO موقت: [D, B]. در این مرحله، کلاس A (والد B) را اضافه نمی‌کنیم، زیرا C نیز از A ارث می‌برد و طبق قوانین باید ابتدا C و سپس A اضافه شود.
3. بررسی والد دوم (C): C به MRO اضافه می‌شود. MRO موقت: [D, B, C].
4. اضافه کردن جد مشترک (A): اکنون که هر دو مسیر به A (یعنی از طریق B و C) در MRO گنجانده شده‌اند، نوبت به خود A می‌رسد. MRO موقت: [D, B, C, A].
5. اضافه کردن ریشه‌ی همه کلاس‌ها (object): در نهایت، کلاس پایه‌ی object به انتهای MRO افزوده می‌شود. MRO نهایی: [D, B, C, A, object].

این فرآیند پیوسته تضمین می‌کند که کلاس A تنها یک بار و در جایگاه صحیح خود (پس از تمام زیرکلاس‌هایش) در زنجیره‌ی جستجو قرار می‌گیرد.

یک نکته‌ی عملی: اگر به هر دلیلی ساختاری تعریف کنید که الگوریتم C3 نتواند ترتیب سازگاری برای آن بیابد (مثلاً ترتیب والدین به گونه‌ای باشد که قوانین را نقض کند)، پایتون بلافاصله و در لحظه‌ی تعریف کلاس، خطای TypeError: Cannot create a consistent method resolution order را پرتاب می‌کند. این یک ویژگی ایمنی عالی است که از بروز خطاهای مرموز در زمان اجرا جلوگیری می‌کند.

Mixinها: استفاده‌ی امن و ماژولار از وراثت چندگانه

با درک خطرات و پیچیدگی‌های وراثت چندگانه، به امن‌ترین و در عین حال قدرتمندترین کاربرد آن می‌رسیم: Mixinها.

Mixin چیست؟

Mixin کلاسی است کوچک و متمرکز که تنها یک قابلیت مشخص و مستقل را پیاده‌سازی می‌کند. هدف از طراحی یک Mixin، افزودن یک رفتار خاص به کلاس‌های دیگر است. یک Mixin به تنهایی موجودیت مستقلی محسوب نمی‌شود و نباید به تنهایی نمونه‌سازی (instantiate) شود. کاربرد اصلی آن، «مخلوط شدن» (mixing in) با کلاس‌های اصلی برای غنی‌سازی قابلیت‌های آنهاست.

تفاوت یک Mixin با یک کلاس معمولی در این است که یک کلاس معمولی نمایانگر یک «چیز» یا موجودیت است (مانند User، Order، Product) در حالی که یک Mixin نمایانگر یک «توانایی» یا رفتار است (مانند JSONableMixin، LoggableMixin، TimestampMixin).

بیایید با یک مثال، این مفهوم را روشن‌تر کنیم:

class JSONMixin:
    """adds JSON conversion capability"""
    def to_json(self):
        import json
        return json.dumps(self.__dict__, ensure_ascii=False)

class TimestampMixin:
    """adds creation-time recording capability"""
    def __init__(self, *args, **kwargs):
        import time
        self.created_at = time.time()
        super().__init__(*args, **kwargs)

class User(TimestampMixin, JSONMixin):
    def __init__(self, name):
        self.name = name
        super().__init__()

u = User("ali")
print(u.to_json())
# {"name": "ali", "created_at": 1690123456.0}
print(u.created_at)
# 1690123456.0

در اینجا، User کلاس اصلی است که هویت اصلی خود را حفظ کرده است. TimestampMixin و JSONMixin تنها قابلیت‌های کوچکی را به آن اضافه کرده‌اند که می‌توانند به راحتی به هر کلاس دیگری نیز متصل شوند. این همان ماژولاریتی و قابلیت استفاده‌ی مجدد بالایی است که Mixinها ارائه می‌دهند.

چه زمانی از Mixin استفاده کنیم و چه زمانی نه؟

زمان استفاده از Mixin:

• زمانی که می‌خواهیم یک قابلیت خاص و مستقل را به چندین کلاس نامرتبط اضافه کنیم (مانند logging، serialization، caching).
• زمانی که رابطه‌ی بین کلاس‌ها از نوع «توانایی انجام دادن» (Can-Do) است، نه «هست» (Is-A). مثلاً یک کلاس User می‌تواند JSONable باشد (توانایی تبدیل به JSON را دارد).

زمان عدم استفاده از Mixin:

• زمانی که رابطه‌ی معنایی قوی «Is-A» بین کلاس‌ها برقرار است. مثلاً Dog یک Animal است. در این موارد از ارث‌بری معمولی استفاده می‌کنیم.
• زمانی که می‌توان با ترکیب (Composition) به همان هدف با سادگی بیشتری دست یافت. (مبحث ترکیب در فصل بعدی پوشش داده خواهد شد).

یک نکته‌ی مهم در نام‌گذاری: برای شفاف‌سازی و جلوگیری از سردرگمی، مرسوم است که نام Mixinها را با پسوند Mixin پایان دهیم (مانند JSONMixin، LogMixin). این کار نیت طراح کد را به خوبی منتقل می‌کند.

تفاوت Mixin با کلاس انتزاعی (Abstract Base Class – ABC)

با وجود شباهت‌های ظاهری، هدف این دو مفهوم کاملاً متفاوت است:

ویژگی	Mixin	کلاس انتزاعی (ABC)
هدف	افزودن پیاده‌سازی آماده و قابل استفاده‌ی مجدد	الزام زیرکلاس‌ها به پیاده‌سازی یک مجموعه متد مشخص (تعریف قرارداد)
متدها	معمولاً شامل متدهای کاملاً پیاده‌سازی شده	معمولاً شامل متدهای انتزاعی (بدون پیاده‌سازی) است
رابطه	«این قابلیت را داشته باش» (Can-Do)	«برای انجام این کار، این قوانین را رعایت کن» (Must-Do)

به عبارت دیگر، Mixin می‌گوید «من این کار را برایت انجام می‌دهم»، در حالی که کلاس انتزاعی می‌گوید «تو باید حتماً این کار را انجام دهی». (مبحث ABCها در فصل نهم به طور کامل بررسی خواهد شد).

مفاهیم پیشرفته‌تر در وراثت

متد __init_subclass__: قلابی برای پیکربندی زیرکلاس‌ها

این متد جادویی که از پایتون نسخه‌ی ۳.۶ به بعد معرفی شده است، یک قلاب (hook) قدرتمند است که در لحظه‌ی تعریف یک زیرکلاس (نه در زمان نمونه‌سازی از آن) فراخوانی می‌شود. این ویژگی، امکان بررسی و پیکربندی خودکار زیرکلاس‌ها را فراهم می‌کند و در بسیاری از موارد، نیاز به متاکلاس‌های پیچیده را برطرف می‌سازد.

یکی از کاربردی‌ترین الگوها با استفاده از این متد، ثبت خودکار (Auto-registration) زیرکلاس‌ها است. برای مثال در سیستم‌های پلاگین‌محور:

class Plugin:
    registry = []  # list to store all subclasses

    def __init_subclass__(cls, **kwargs):
        super().__init_subclass__(**kwargs)
        Plugin.registry.append(cls)  # auto-register the class
        print(f"Plugin registered: {cls.__name__}")

class EmailPlugin(Plugin):
    pass

class SMSPlugin(Plugin):
    pass

# output at definition time (not object creation):
# Plugin registered: EmailPlugin
# Plugin registered: SMSPlugin

print([c.__name__ for c in Plugin.registry])
# ['EmailPlugin', 'SMSPlugin']

کاربرد دیگر این متد، الزام زیرکلاس‌ها به رعایت یک قرارداد است. به عنوان مثال، می‌توانیم مطمئن شویم که هر زیرکلاسی یک متد خاص را پیاده‌سازی کرده است:

class Handler:
    def __init_subclass__(cls, **kwargs):
        super().__init_subclass__(**kwargs)
        if not hasattr(cls, "handle"):
            raise TypeError(f"{cls.__name__} must have a handle method")

class GoodHandler(Handler):
    def handle(self):
        pass

# class BadHandler(Handler):  # this would raise TypeError
#     pass

قاعده‌ی کلی: اگر هدف شما فقط انجام یک عملیات ساده در زمان تعریف زیرکلاس (مانند ثبت، اعتبارسنجی یا تزریق پیکربندی) است، __init_subclass__ گزینه‌ای کاملاً مناسب و ساده‌تر از متاکلاس محسوب می‌شود. متاکلاس‌ها که برای کنترل عمیق‌تر بر فرآیند ساخت کلاس به کار می‌روند، در فصول پیشرفته‌تر (فصل شانزدهم) به طور کامل پوشش داده خواهند شد.

خلاصه و نتیجه‌گیری

در این فصل، سفر خود را از وراثت ساده به دنیای پیچیده‌تر اما قدرتمند وراثت چندگانه آغاز کردیم. دیدیم که چگونه الگوریتم C3 با ایجاد ترتیب MRO، مسئله‌ی الماس را حل می‌کند و با قاعده‌ی استفاده از super() می‌توانیم زنجیره‌ای منظم و قابل پیش‌بینی از اجرای متدها داشته باشیم.

مهم‌ترین آموزه‌ی این فصل، کاربرد امن و هدفمند وراثت چندگانه از طریق Mixinها بود. Mixinها به عنوان بلوک‌های سازنده‌ی کوچک و متمرکز بر رفتار، به ما اجازه می‌دهند تا قابلیت‌های متنوعی را به کلاس‌های مختلف اضافه کنیم، بدون اینکه آن‌ها را در سلسله‌مراتب‌های عمیق و پیچیده‌ی Is-A گرفتار کنیم.

در نهایت، با ابزارهای پیشرفته‌ای مانند __init_subclass__ آشنا شدیم که کنترل و انعطاف‌پذیری بیشتری در طراحی کلاس‌ها در اختیار ما قرار می‌دهند. به خاطر داشته باشید که وراثت چندگانه، مانند هر ابزار قدرتمند دیگری، نیازمند درک، انضباط و رعایت اصول است. در غیر این صورت، می‌تواند به منبعی برای پیچیدگی و خطا تبدیل شود. در فصل بعد، با رویکرد ترکیب (Composition) آشنا خواهیم شد که در بسیاری از موارد، جایگزینی انعطاف‌پذیرتر و ساده‌تر برای ارث‌بری محسوب می‌شود.