أنماط التصميم في بايثون

طريقان إلى نفس الفكرة

الأساسيات المطلوبة

هذا الجزء يبني مباشرة على ما تعلمته في الجزء التاسع، كل نمط تصميم هنا سترسمه أصلاً كـ Class Diagram. تحتاج أيضًا إلى:

المفاهيم الأساسية

نمط التصميم (Design Pattern) ليس قالب كود جاهز للنسخ، بل وصف لبنية مسؤوليات أثبتت نجاحها في حل مشكلة تصميم متكررة. هو إجابة عن ثلاثة أسئلة: ما المشكلة؟ من هي الأطراف المشاركة وأدوارها؟ ولماذا هذا التركيب تحديدًا يجعل التغيير المستقبلي أسهل وأكثر أمانًا؟

4المبدآن الحاكمان في المشروع

الأنماط الثلاثة بالتفصيل

1️⃣ Factory: مركزية الإنشاء

المشكلة: إنشاء الكائنات مبعثر عبر الكود بجُمل if/elif متكررة. كل نوع جديد يعني فتح نفس الدالة القديمة وتعديلها، انتهاك مباشر لمبدأ الفتح والإغلاق.

## ❌ الطريقة الهشّة: كل نوع جديد يعني تعديل هذه الدالة
def create_shape(kind):
    if kind == "circle":
        return Circle()
    elif kind == "square":
        return Square()
    # إضافة "triangle" تعني العودة لتعديل هذا الكود...

الرسم 13: نمط Factory القائم على سجل (Registry): الدالة create() لا تتغيّر أبدًا؛ الأنواع الجديدة تُسجَّل من الخارج.

## ✅ الحل: سجل خارجي (Registry) لا يمسّ منطق الإنشاء الأساسي أبدًا
class ShapeFactory:
    def __init__(self):
        self._registry = {}

    def register_kind(self, name, cls):
        self._registry[name] = cls

    def create(self, kind):
        return self._registry[kind]()  # no if/elif branch, ever

factory = ShapeFactory()
factory.register_kind("circle", Circle)
factory.register_kind("square", Square)
# adding a new shape later never touches create():
factory.register_kind("triangle", Triangle)

2️⃣ Observer: الفصل بين المُصدر وردود الفعل

المشكلة: كائن واحد (ناشر/Publisher) يجب أن يُخبر عدة كائنات أخرى (مراقبين/Observers) عند تغيّر حالته، دون أن "يعرف" تفاصيلهم أو يتكوّد اسمهم مباشرة داخله.

الرسم 14: محطة الطقس (Subject) لا "تعرف" شاشة الهاتف أو الموقع تحديدًا؛ فقط تعرف أنها "مراقبون" يملكون update()‏.

class WeatherStation:
    def __init__(self):
        self._observers = []

    def attach(self, observer):
        self._observers.append(observer)

    def set_temperature(self, value):
        self._temperature = value
        for obs in self._observers:      # لا تعرف أنواعهم الحقيقية
            obs.update(self._temperature)

class PhoneDisplay:
    def update(self, temperature):
        print(f"📱 الجو الآن: {temperature}°")

station = WeatherStation()
station.attach(PhoneDisplay())
station.set_temperature(31)

الرسم 15: نفس النمط بمنظور Sequence Diagram: لاحظ حلقة notify التي تستدعي كل مراقب بدون أن تفرّق بينهم.

3️⃣ Decorator: تركيب السلوك بدل تكديس الوراثة

المشكلة: كائن أساسي له ميزات اختيارية قابلة للدمج (مثل إضافات طلب بيتزا). الوراثة تحتاج كلاسًا فرعيًا لكل توليفة ممكنة، عدد الكلاسات ينفجر مع كل ميزة جديدة.

الرسم 16: كل إضافة (Topping) "تغلّف" بيتزا أخرى وتضيف تكلفتها فقط، دون المساس بالكلاسات الموجودة.

class Pizza:
    def cost(self): return 8.0
    def description(self): return "بيتزا عادية"

class ToppingDecorator(Pizza):
    def __init__(self, wrapped: Pizza):
        self._wrapped = wrapped

class CheeseTopping(ToppingDecorator):
    def cost(self): return self._wrapped.cost() + 1.5
    def description(self): return self._wrapped.description() + " + جبن"

class OliveTopping(ToppingDecorator):
    def cost(self): return self._wrapped.cost() + 1.0
    def description(self): return self._wrapped.description() + " + زيتون"

order = OliveTopping(CheeseTopping(Pizza()))
print(order.description(), "->", order.cost())
# output: بيتزا عادية + جبن + زيتون -> 10.5

مثال محلول

خرافة مقابل حقيقة

أين تُستخدم هذه الأنماط فعليًا؟

جرّب بنفسك

بطاقات مراجعة سريعة

اختبر فهمك