ليس عليك الالتزام الصارم بهذه المبادئ، ولا توجد عقوبات دينية لمخالفتها. ولكن يجب أن تفكر في هذه المبادئ باعتبارها أجراس إنذار إذا تم انتهاك أحدها، فسوف يدق جرس الإنذار. ----- Arthur J.Riel
(1) يجب إخفاء جميع البيانات داخل الفصل الذي توجد فيه.
(2) يجب أن يعتمد مستخدمو الفصل على الواجهة المشتركة للفئة، لكن لا يمكن للفئة الاعتماد على مستخدميها.
(3) تصغير الرسائل في بروتوكول الفصل.
(4) تنفيذ الواجهة العامة الأساسية التي تفهمها جميع الفئات [على سبيل المثال، عمليات النسخ (النسخة العميقة والنسخة السطحية)، وحكم المساواة، ومحتوى الإخراج الصحيح، والتحليل من وصف ASCII، وما إلى ذلك].
(5) لا تضع تفاصيل التنفيذ (مثل الوظائف الخاصة التي تضع تعليمات برمجية مشتركة) في الواجهة العامة للفئة.
إذا كانت هناك طريقتان لفئة تحتوي على جزء مشترك من التعليمات البرمجية، فيمكنك إنشاء وظيفة خاصة تمنع هذا الرمز المشترك.
(6) لا تزعج الواجهة العامة للفصل بأشياء لا يستطيع المستخدمون استخدامها أو لا يهتمون بها.
(7) ينبغي ألا يكون هناك أي اقتران بين الفئات، أو علاقات اقتران مشتقة فقط. وهذا يعني أن فئة واحدة إما لا علاقة لها بفئة أخرى، أو أنها تستخدم فقط العمليات في الواجهة العامة لفئة أخرى.
(8) يجب أن يمثل الفصل تجريدًا رئيسيًا واحدًا فقط.
يجب إغلاق جميع الفئات الموجودة في الحزمة بشكل مشترك لإجراء تغييرات في نفس نوع الخصائص. إذا أثر التغيير على الحزمة، فسيؤثر على جميع الفئات الموجودة في الحزمة، ولكن لن يكون له أي تأثير على الحزم الأخرى
(9) مركزة البيانات والسلوكيات ذات الصلة.
يجب أن يكون المصممون على دراية بالكائنات التي تحصل على البيانات من كائنات أخرى من خلال عمليات مثل get. هذا النوع من السلوك يعني انتهاك هذا المبدأ التجريبي.
(10) ضع المعلومات غير ذات الصلة في فئة أخرى (أي سلوك عدم التواصل مع بعضهم البعض).
قم بإنشاء تبعيات لتحقيق الاستقرار
(11) تأكد من أن المفاهيم المجردة التي تقوم بنموذجها هي فئات، وليست فقط الأدوار التي تلعبها الكائنات.
(12) توزيع وظائف النظام بشكل موحد قدر الإمكان في الاتجاه الأفقي، أي: وفقًا للتصميم، يجب أن تتقاسم فصول المستوى الأعلى العمل بشكل موحد.
(13) لا تقم بإنشاء فئات/كائنات كلية القدرة في نظامك. كن حذرًا بشكل خاص مع الفئات التي تتضمن أسماؤها Driver وManager وSystem وSusystem.
تخطيط واجهة بدلاً من تنفيذ واجهة.
(14) كن حذرًا مع الفئات التي تحدد عددًا كبيرًا من طرق الوصول في الواجهة العامة. ويعني العدد الكبير من طرق الوصول أن البيانات والسلوكيات ذات الصلة لا يتم تخزينها مركزيًا.
(15) كن حذرًا من الفصول التي تحتوي على الكثير من السلوكيات التي لا تتواصل مع بعضها البعض.
مظهر آخر لهذه المشكلة هو إنشاء الكثير من وظائف الحصول والضبط في الواجهة العامة للفئات في تطبيقك.
(16) في تطبيق يتكون من نموذج موجه للكائنات يتفاعل مع واجهة المستخدم، يجب ألا يعتمد النموذج على الواجهة، ولكن يجب أن تعتمد الواجهة على النموذج.
(17) النموذج وفقًا للعالم الحقيقي قدر الإمكان (غالبًا ما ننتهك هذا المبدأ من أجل الامتثال لمبدأ توزيع وظائف النظام، وتجنب مبدأ الطبقة لجميع الأغراض، ووضع البيانات والسلوكيات ذات الصلة مركزيًا).
(18) قم بإزالة الفئات غير الضرورية من التصميم الخاص بك.
بشكل عام، سنقوم بتخفيض تصنيف هذه الفئة إلى خاصية.
(19) إزالة الفئات خارج النظام.
إن خاصية الفئات خارج النظام هي أنها، بشكل مجرد، ترسل رسائل إلى مجال النظام فقط ولكنها لا تقبل رسائل من فئات أخرى في مجال النظام.
(20) لا تحول العمليات إلى فئات. قم بسؤال أي فصل اسمه فعل أو مشتق من فعل، خاصة الفصل الذي له فعل واحد فقط ذو معنى. فكر فيما إذا كان ينبغي نقل هذا السلوك ذي المعنى إلى فصل موجود بالفعل أو لم يتم اكتشافه بعد.
(21) غالبًا ما نقدم فئات الوكيل عند إنشاء نماذج تحليل التطبيقات. أثناء مرحلة التصميم، غالبًا ما نجد أن العديد من العوامل عديمة الفائدة ويجب إزالتها.
(22) تقليل عدد المتعاونين في الفصل.
يجب أن يظل عدد الفصول الأخرى التي يستخدمها الفصل عند الحد الأدنى.
(23) تقليل عدد الرسائل التي يتم تمريرها بين الفصول والمتعاونين.
(24) تقليل مقدار التعاون بين الفصول والمتعاونين، أي: تقليل عدد الرسائل المختلفة التي يتم تمريرها بين الفصول والمتعاونين.
(25) تقليل انتشار الفصل، أي تقليل ناتج عدد الرسائل المحددة بواسطة الفصل وعدد الرسائل المرسلة.
(26) إذا كانت الفئة تحتوي على كائن من فئة أخرى، فيجب أن ترسل الفئة المحتوية رسالة إلى الكائن المتضمن. وهذا يعني أن علاقة التضمين تنطوي دائمًا على علاقة استخدام.
(27) يجب أن تستخدم معظم الطرق المحددة في الفصل معظم أعضاء البيانات في معظم الأوقات.
(28) يجب ألا يتجاوز عدد الكائنات الموجودة في الفصل سعة الذاكرة قصيرة المدى للمطور. هذا الرقم غالبا ما يكون 6.
عندما يحتوي الفصل على أكثر من 6 أعضاء بيانات، يمكنك تقسيم أعضاء البيانات المرتبطة منطقيًا إلى مجموعة، ثم استخدام فئة تحتوي على جديدة لاحتواء هذه المجموعة من الأعضاء.
(29) لتتوزع وظائف النظام عموديا في نظام وراثة ضيق وعميق.
(30) عند تنفيذ القيود الدلالية، فمن الأفضل تنفيذها وفقًا لتعريفات الفئة. يؤدي هذا غالبًا إلى تجاوز سعة الفصل، وفي هذه الحالة يجب تنفيذ القيود في سلوك الفصل، عادةً ولكن ليس بالضرورة في المُنشئ.
(31) عند تنفيذ القيود الدلالية في منشئ الفصل، ضع اختبار القيد في أعمق مستوى تضمين يسمح به مجال المنشئ.
(32) إذا كانت المعلومات الدلالية التي تعتمد القيود عليها تتغير بشكل متكرر، فمن الأفضل وضعها في كائن مركزي تابع لجهة خارجية.
(33) إذا كانت المعلومات الدلالية التي تعتمد عليها القيود نادرًا ما تتغير، فمن الأفضل توزيعها بين الفئات المشاركة في القيود.
(34) يجب أن يعرف الفصل ما يحتوي عليه، لكنه لا يستطيع معرفة من يحتوي عليه.
(35) لا ينبغي أن يكون للكائنات التي تشترك في النطاق الحرفي (أي المضمنة في نفس الفئة) علاقة استخدام مع بعضها البعض.
(36) يجب استخدام الميراث فقط لنموذج التسلسل الهرمي للتخصص.
(37) يجب أن تعرف الفئات المشتقة عن الفئات الأساسية، ويجب ألا تعرف الفئات الأساسية أي معلومات عن فئاتها المشتقة.
(38) يجب أن تكون جميع البيانات الموجودة في الفئة الأساسية خاصة، ولا تستخدم البيانات المحمية.
لا ينبغي لمصممي الفصل أبدًا وضع أشياء في واجهة عامة لا يحتاجها مستخدمو الفصل.
(39) من الناحية النظرية، يجب أن يكون التسلسل الهرمي للميراث أعمق، وكلما كان أعمق كلما كان ذلك أفضل.
(40) في الممارسة العملية، يجب ألا يتجاوز عمق التسلسل الهرمي للميراث سعة الذاكرة قصيرة المدى للشخص العادي. قيمة العمق المقبولة على نطاق واسع هي 6.
(41) يجب أن تكون جميع الفئات المجردة فئات أساسية.
(42) يجب أن تكون جميع الفئات الأساسية فئات مجردة.
(43) ضع البيانات والسلوك و/أو القواسم المشتركة للواجهة في أعلى مستوى ممكن في التسلسل الهرمي للميراث.
(44) إذا كان هناك فئتان أو أكثر يتشاركان في بيانات مشتركة (ولكن لا يوجد سلوك مشترك)، فيجب وضع البيانات المشتركة في فئة مضمنة في كل فئة تشترك في هذه البيانات.
(45) إذا كان لدى فئتين أو أكثر بيانات وسلوك مشترك (أي طرق)، فيجب أن ترث كل فئة من هذه الفئات من فئة أساسية مشتركة تمثل هذه البيانات والأساليب.
(46) إذا كان هناك فئتان أو أكثر تشتركان في واجهة مشتركة (تشير إلى الرسائل، وليس الأساليب)، فيجب أن يرثوا من فئة أساسية مشتركة فقط إذا كانوا بحاجة إلى استخدامها بشكل متعدد الأشكال.
(47) يعد تحليل عرض أنواع الكائنات على أساس كل حالة على حدة أمرًا خاطئًا بشكل عام. في معظم هذه الحالات، يجب على المصممين استخدام تعدد الأشكال.
(48) غالبًا ما يكون تحليل عرض قيم السمات على حدة أمرًا خاطئًا. يجب فصل الفئات إلى تسلسل هرمي للوراثة، مع تحويل كل قيمة سمة إلى فئة مشتقة.
(49) لا تضع نموذجًا للدلالات الديناميكية للفئة من خلال علاقات الميراث. تؤدي محاولة نمذجة الدلالات الديناميكية باستخدام العلاقات الدلالية الثابتة إلى تبديل الأنواع في وقت التشغيل.
(50) لا تقم بتحويل كائنات الفئة إلى فئات مشتقة. كن حذرًا مع أي فئة مشتقة تحتوي على مثيل واحد فقط.
(51) إذا كنت تعتقد أنك بحاجة إلى إنشاء فئة جديدة في وقت التشغيل، فتراجع خطوة إلى الوراء وأدرك أنك تقوم بإنشاء كائنات. الآن، تعميم هذه الكائنات في فئة.
(52) يجب أن يكون من غير القانوني استخدام طريقة فارغة (أي طريقة لا تفعل شيئًا) في فئة مشتقة لتجاوز طريقة في الفئة الأساسية.
(53) لا تخلط بين الضم الاختياري وضرورة الميراث. نمذجة التضمين الاختياري كميراث يؤدي إلى انتشار الطبقات.
(54) عند إنشاء تسلسلات هرمية للوراثة، حاول إنشاء أطر قابلة لإعادة الاستخدام بدلاً من المكونات القابلة لإعادة الاستخدام.
(55) إذا كنت تستخدم الوراثة المتعددة في تصميمك، فافترض أنك ارتكبت خطأ. إذا لم ترتكب خطأ، فأنت بحاجة إلى محاولة إثبات ذلك.
(56) عندما يتم استخدام الوراثة في التصميم الموجه للكائنات، اسأل نفسك سؤالين: (1) هل الفئة المشتقة هي نوع خاص من الشيء الذي ترثه؟ (2) هل الفئة الأساسية جزء من الفئة المشتقة؟
(57) إذا وجدت وراثة متعددة في تصميم موجه للكائنات، فتأكد من عدم وجود فئة أساسية هي في الواقع فئة مشتقة من فئة أساسية أخرى.
(58) في التصميم الموجه للكائنات، إذا كنت بحاجة إلى الاختيار بين التضمين والارتباط، فيرجى اختيار التضمين.
(59) لا تستخدم البيانات العالمية أو الوظائف العالمية لمسك دفاتر كائنات الفئة. يجب استخدام متغيرات الفئة أو أساليب الفئة.
(60) يجب على المصممين الموجهين للكائنات ألا يسمحوا لمبادئ التصميم المادي بتقويض تصميماتهم المنطقية. ومع ذلك، فإننا غالبًا ما نستخدم معايير التصميم المادي في اتخاذ القرارات المتعلقة بالتصميم المنطقي.
(61) لا تتجاوز الواجهة العامة لتعديل حالة الكائن.