 
   - بواسطة x32x01 ||
تخيل إنك مطور وعامل تطبيق توصيل طلبات شغال كويس جدًا،
عندك عربيات بتوصل الطلبات بين المحافظات وكل حاجة تمام.
وفجأة التطبيق بتاعك كبر وبقى فيه آلاف المستخدمين،
وبدأت تفكر في التوسيع أكتر وأكتر
 
وفجأة!
رجل أعمال كبير بيكلمك وبيقولك:
"أنا عايز أستثمر معاك، بس لازم تضيف وسيلة توصيل جديدة... عن طريق البحر !"
!"
 
وطبعًا الموضوع مغري جدًا، بس فيه مشكلة ضخمة في الكود
 
 
 المشكلة اللي كل المبرمجين بيقعوا فيها 
أنت عندك Class اسمه مثلاً:
    دلوقتي عايز تضيف شحن بحري (Ship).
إيه اللي بيحصل؟
بتعمل Copy-Paste للكود القديم وتبدأ تعدل فيه شوية:
    وبعد كده كل ما تضيف نوع توصيل جديد (زي الطيارة  )،
)،
هتكرر نفس الكود تاني وتاني وتاني
 
النتيجة؟
الكود بقى متكركب، صعب تعدّل فيه،
وأي حاجة بسيطة ممكن تبوّظ المشروع كله!
 
 
 الحل: استخدم الـ Interface والـ Factory 
الحل الذكي هنا إنك تطبق مبدأ البرمجة الكائنية (OOP)
وتستخدم Design Pattern اسمه Factory.
 
أول خطوة
هتعمل Interface عام بيعرّف طريقة التوصيل الأساسية:
    
وبعدين أي وسيلة توصيل جديدة هتعمل Implement للـ Interface ده
    دلوقتي كل وسيلة توصيل عندها لوجيكها الخاص
بس كلها بتلتزم بنفس الطريقة (deliver).
 
 
 هنا ييجي دور الـ Factory 
بدل ما تنادي كل وسيلة توصيل لوحدها في الكود،
هتعمل Class جديدة اسمها Logistics أو TransportFactory،
وهي دي اللي هتقرر أي وسيلة تستخدمها
    
وبعدين في الكود الأساسي (Client Code):
    النتيجة؟
تقدر تضيف وسيلة توصيل جديدة بسهولة جدًا من غير ما تلخبط الكود القديم
 
 
 فايدة الـ Factory Design Pattern 
الميزة الكبيرة في الـ Factory Pattern إنه بيساعدك تحقق Scalability حقيقية.
يعني لو بكرة قررت تضيف توصيل جوي
كل اللي هتعمله إنك تضيف Class جديدة،
وتربطها بالـ Factory وخلاص!
 
مفيش كود بيتكرر،
مفيش Bugs بسبب Copy/Paste،
والمشروع بيكبر بسهولة ومن غير مشاكل
 
 
 فين ممكن تستخدم الفكرة دي؟ 
مش بس في التوصيل!
الـ Factory Design Pattern ينفع في أي حاجة فيها أنواع مختلفة:
 
بس خلي بالك
لو كل نوع مجرد "اسم" من غير منطق (Logic)،
يبقى استخدام الـ Factory هنا Over Engineering.
يعني زيادة تعقيد على الفاضي
 
 
 ليه لازم تتعلم الـ Design Patterns؟ 
الـ Design Patterns هي من أهم أدوات المبرمج المحترف.
في منها 3 أنواع رئيسية:
 
كل نوع بيساعدك تفهم إزاي تبني مشروعك صح
من ناحية البنية، والسلوك، وطريقة تعامل الكلاسات والفانكشنات مع بعض.
 
 
 الخلاصة 
لو عايز تبني مشروع قابل للتوسيع ومفيهوش مشاكل مستقبلية،
بلاش تعتمد على Copy/Paste Coding.
استخدم مبادئ الـ OOP، وابدأ تتعلم Design Patterns واحدة واحدة.
 
ابدأ بـ Factory Design Pattern لأنه الأسهل والأوضح،
وهيساعدك تفكر زي مهندس برمجيات حقيقي مش مجرد كاتب كود

 عندك عربيات بتوصل الطلبات بين المحافظات وكل حاجة تمام.
وفجأة التطبيق بتاعك كبر وبقى فيه آلاف المستخدمين،
وبدأت تفكر في التوسيع أكتر وأكتر

وفجأة!

رجل أعمال كبير بيكلمك وبيقولك:
"أنا عايز أستثمر معاك، بس لازم تضيف وسيلة توصيل جديدة... عن طريق البحر
 !"
!"وطبعًا الموضوع مغري جدًا، بس فيه مشكلة ضخمة في الكود

المشكلة اللي كل المبرمجين بيقعوا فيها  
أنت عندك Class اسمه مثلاً: Java: 
 class Truck {
  void deliver() {
    System.out.println("Delivery by truck 🚚");
  }
}إيه اللي بيحصل؟

بتعمل Copy-Paste للكود القديم وتبدأ تعدل فيه شوية:
 Java: 
 class Ship {
  void deliver() {
    System.out.println("Delivery by sea 🛳️");
  }
} )،
)،هتكرر نفس الكود تاني وتاني وتاني

النتيجة؟
الكود بقى متكركب، صعب تعدّل فيه،
وأي حاجة بسيطة ممكن تبوّظ المشروع كله!
الحل: استخدم الـ Interface والـ Factory 
 
الحل الذكي هنا إنك تطبق مبدأ البرمجة الكائنية (OOP)وتستخدم Design Pattern اسمه Factory.
أول خطوة

هتعمل Interface عام بيعرّف طريقة التوصيل الأساسية:
 Java: 
 interface Transport {
  void deliver();
}وبعدين أي وسيلة توصيل جديدة هتعمل Implement للـ Interface ده

 Java: 
 class Truck implements Transport {
  public void deliver() {
    System.out.println("Delivery by truck 🚚");
  }
}
class Ship implements Transport {
  public void deliver() {
    System.out.println("Delivery by sea 🛳️");
  }
}بس كلها بتلتزم بنفس الطريقة (deliver).
هنا ييجي دور الـ Factory  
بدل ما تنادي كل وسيلة توصيل لوحدها في الكود،هتعمل Class جديدة اسمها Logistics أو TransportFactory،
وهي دي اللي هتقرر أي وسيلة تستخدمها

 Java: 
 class TransportFactory {
  public Transport getTransport(String type) {
    if (type.equals("truck")) {
      return new Truck();
    } else if (type.equals("ship")) {
      return new Ship();
    } else {
      throw new IllegalArgumentException("Unknown transport type");
    }
  }
}وبعدين في الكود الأساسي (Client Code):
 Java: 
 public class Main {
  public static void main(String[] args) {
    TransportFactory factory = new TransportFactory();
    Transport t1 = factory.getTransport("truck");
    t1.deliver();
    Transport t2 = factory.getTransport("ship");
    t2.deliver();
  }
}تقدر تضيف وسيلة توصيل جديدة بسهولة جدًا من غير ما تلخبط الكود القديم

فايدة الـ Factory Design Pattern  
الميزة الكبيرة في الـ Factory Pattern إنه بيساعدك تحقق Scalability حقيقية.يعني لو بكرة قررت تضيف توصيل جوي

كل اللي هتعمله إنك تضيف Class جديدة،
وتربطها بالـ Factory وخلاص!
مفيش كود بيتكرر،
مفيش Bugs بسبب Copy/Paste،
والمشروع بيكبر بسهولة ومن غير مشاكل

فين ممكن تستخدم الفكرة دي؟  
مش بس في التوصيل!الـ Factory Design Pattern ينفع في أي حاجة فيها أنواع مختلفة:
- أنواع مستخدمين (Admin, Customer, Driver)  
- أنواع منتجات أو Tasks  
- أو حتى أنواع إشعارات (Email, SMS, Push)  
بس خلي بالك

لو كل نوع مجرد "اسم" من غير منطق (Logic)،
يبقى استخدام الـ Factory هنا Over Engineering.
يعني زيادة تعقيد على الفاضي

ليه لازم تتعلم الـ Design Patterns؟  
الـ Design Patterns هي من أهم أدوات المبرمج المحترف.في منها 3 أنواع رئيسية:
- Creational Patterns → زي Factory و Singleton.
- Structural Patterns → زي Adapter و Decorator.
- Behavioral Patterns → زي Observer و Strategy.
كل نوع بيساعدك تفهم إزاي تبني مشروعك صح
من ناحية البنية، والسلوك، وطريقة تعامل الكلاسات والفانكشنات مع بعض.
الخلاصة  
لو عايز تبني مشروع قابل للتوسيع ومفيهوش مشاكل مستقبلية،بلاش تعتمد على Copy/Paste Coding.
استخدم مبادئ الـ OOP، وابدأ تتعلم Design Patterns واحدة واحدة.
ابدأ بـ Factory Design Pattern لأنه الأسهل والأوضح،
وهيساعدك تفكر زي مهندس برمجيات حقيقي مش مجرد كاتب كود


