كم عدد مبادئ تصميم الأنماط بالضبط؟
Categories:
تم تلخيص مبادئ تصميم الأنماط في البداية إلى 5 فقط، أي SOLID:
مبدأ المسؤولية الفردية (Single Responsibility Principle, SRP): يجب أن يكون للصنف سبب واحد فقط لتغييره، أي يجب أن يكون للصنف مسؤولية واحدة فقط.مبدأ الفتح/الإغلاق (Open/Closed Principle, OCP): يجب أن تكون الكيانات البرمجية (الصنف، الوحدة، الدالة إلخ) مفتوحة للتوسعة ومغلقة للتعديل، أي يجب أن يتم تحقيق التغيرات من خلال التوسعة وليس من خلال تعديل الكود الموجود.مبدأ استبدال ليسكوف (Liskov Substitution Principle, LSP): يجب أن تكون الأصناف الفرعية قادرة على استبدال صنفها الأساسي، أي يجب أن تكون الأصنف المشتقة قادرة على استبدال صنفها الأساسي دون التأثير على صحة البرنامج.مبدأ عزل الواجهة (Interface Segregation Principle, ISP): لا ينبغي إجبار العميل على الاعتماد على الواجهات التي لا يستخدمها. يجب تقسيم الواجهات الكبيرة إلى واجهات أصغر وأكثر تحديدًا، بحيث يحتاج العميل إلى معرفة الطرق التي يحتاج إلى استخدامها فقط.مبدأ انعكاس الاعتماد (Dependency Inversion Principle, DIP): لا ينبغي أن يعتمد المستوى الأعلى على المستوى الأدنى، بل ينبغي أن يعتمدا معًا على المُجرّد. لا ينبغي أن يعتمد المجرّد على تفاصيل التنفيذ، بل يجب أن تعتمد تفاصيل التنفيذ على المجرّد.
لاحقًا أُضيف مبدأان، هذه القواعد الإضافية أدق وأكثر توجيهًا مقارنة بالقواعد السابقة. يمكننا رؤية من شرح المبادئ أن SOLID تصف ما يجب فعله، بينما تصف القواعد الإضافية ما يجب تفضيله أو أفضل ما يمكن فعله.
مبدأ إعادة استخدام التركيب/التجميع (Composition/Aggregation Reuse Principle, CARP): يجب إعطاء الأولوية لاستخدام تكوين الكائنات (التركيب) والتجميع بدلاً من الوراثة لتحقيق إعادة استخدام الكود.قانون ديميتر (Law of Demeter, LoD): يجب أن يكون للكائن معرفة بأقل قدر ممكن بالكائنات الأخرى، أي يجب أن يعرف الكائن أقل قدر ممكن من التفاصيل عن بنية وتنفيذ الكائنات الأخرى.
بجانب المبادئ التصميمية الشائعة المذكورة أعلاه، هناك بعض مبادئ التصميم الأخرى التي قد لا تكون معروفة على نطاق واسع مثل المبادئ السابقة، لكن لها أيضًا دور مهم في توجيه تصميم وبنية البرمجيات. هذه القواعد المضافة لاحقًا، تبدو نوعًا ما زائدة عن الحاجة، على الأقل أعتقد أنها ليست غير بديهية ولا تحتاج إلى تفكير عميق.
مبدأ أقل معرفة (Principle of Least Knowledge, PoLK): يُعرف أيضًا بامتداد لقانون ديميتر، ويدعو إلى أن يكون للكائن معرفة بأقل قدر ممكن من معلومات الكائنات الأخرى. يعود أصل هذا المبدأ إلى عام 1987 عندما قدمته باتريشيا لاجو (Patricia Lago) وكوس فيسر (Koos Visser) كـ"قانون أقل اتصال".مبدأ الاعتماد المستقر (Stable Dependencies Principle, SDP): ينص هذا المبدأ على أن تصميم البرمجيات يجب أن يضمن عدم اعتماد المكونات المستقرة على المكونات غير المستقرة، أي يجب أن تعتمد المكونات ذات الاستقرار الأعلى أقل على المكونات ذات الاستقرار الأدنى. تعود فكرة هذا المبدأ إلى الدراسة المتعمقة للعلاقات بين المكونات في نظم البرمجيات.مبدأ التجريد المستقر (Stable Abstraction Principle, SAP): يتماشى مع مبدأ الاعتماد المستقر، ويوجه مطابقة التجريد مع الاستقرار، أي يجب أن تكون المكونات المستقرة مجردة، بينما يجب أن تكون المكونات غير المستقرة ملموسة. يساعد هذا المبدأ في ضمان استقرار ومرونة نظام البرمجيات.