في إصدار حديث من DotNet & More podcast ، ناقشنا مع مكسيم Arshinov تقريره القادم عن موسكو. التالي "The Shine and Poverty of the Model Model". يمكن الوصول بسهولة إلى موقع Maxim في المؤتمر مباشرة. وبالإضافة إلى ذلك ، أود أن أعتبر رؤية لنقاش كبير لنماذج مجال Anemic VS "الغنية" ("الغنية") من خلال منظور قوالب GRASP ذات الشعبية
استمرت المناقشات لفترة طويلة ، على سبيل المثال:
قبل البدء في التحليل ، أود أن أوضح موضوع النزاع. الفرق الرئيسي بين النموذج الغاضب والنموذج الغني هو أنه لا يحتوي على منطق تجاري في نص الفصل. قد يكون نموذج DTO المعروف مثالاً معروفًا للنموذج المصاب بفقر الدم.
قد يحتوي النموذج "الغني" بدوره على منطق يصف قواعد العمل ووظائفه ، إلخ. يرجى ملاحظة أننا ندرس الأساليب التي تعكس منطق العمل. لا يتم تضمين ToString و GetHashCode والأجزاء "الفنية" الأخرى من الفئات في المناقشة ، وبالتالي يتم تجاهلها.
GRASP
كما لوحظ في بداية المقالة ، سننظر في هذه المشكلة في سياق أنماط GRASP . تم تقديم هذه المجموعة من القوالب في كتاب Craig Larman "استخدام UML وأنماط التصميم" وأثرت بشكل كبير على البرمجة الحديثة ، على سبيل المثال ، تم الإعلان عن قواعد Low Coupling / High Cohesion في GRASP.
بالنسبة للأشخاص المطلعين على أنماط GoF ، قد تبدو هذه المجموعة من الضبابية ضبابية للغاية. الشيء هو أن أنماط GRASP لا تركز على حل المشكلات المطبقة ، ولكن على توزيع المسؤولية عن بعض الإجراءات والعمليات بين الكائنات:
- الخالق هو المسؤول عن إنشاء الكائنات.
- المراقب هو المسؤول عن العمليات من المستخدمين
- Indirection هي المسؤولة عن تنظيم ضعف الربط بين الكائنات.
و هكذا.
في سياق هذه المقالة ، أود التركيز على الأنماط التالية:
المشكلة: ما هو المبدأ الأساسي لتقاسم المسؤوليات بين المنشآت؟
الحل: خصص هذا الواجب لفئة لديها معلومات كافية لتنفيذها.
بمعنى آخر:
يجب تعيين المسؤولية إلى الشخص الذي يملك الحد الأقصى من المعلومات اللازمة للتنفيذ - خبير المعلومات.
في سياق C # : يجب الإعلان عن طريقة في الفصل الذي تستخدم حقوله وخصائصه في هذه الطريقة.
على سبيل المثال ، إذا كانت قيمة المعلومات المطلوبة في حساب المدين هي جوهر المدين (مقدار ووقت إصدار القرض) ، فيجب في هذه الحالة الإعلان عن الطريقة المناسبة.
بالطبع ، هذا التبسيط مفرط إلى حد ما ، ولكن النقطة الرئيسية يجب أن تكون واضحة.
تلفيق نقي
المشكلة: ما هي الفئة التي ينبغي أن توفر تطبيق High Cohesion و Low Coupling إذا كان قالب معلومات الخبراء لا يوفر حلاً مناسبًا.
الحل: عيّن مجموعة من الواجبات بدرجة عالية من المشاركة في فئة مصطنعة لا تمثل مفهومًا محددًا للموضوع.
بمعنى آخر:
إذا لم يكن من الممكن تحديد الكيان المناسب لنموذج الموضوع بشكل لا لبس فيه ، والذي يمكن إسناد المسؤولية إليه ، فمن الضروري إنشاء فئة اصطناعية غير موجودة في مجال الموضوع.
في سياق C # : إذا كان تنفيذ الطريقة ينص على الاستخدام الموحد للعديد من الكيانات أو التبعيات الخارجية ، فينبغي الإعلان عن هذه الطريقة في فصل منفصل. وتسمى هذه الفئات الخدمات.
على سبيل المثال ، إذا كنت تريد حساب مبلغ الدين ، فأنت بحاجة إلى معرفة ليس فقط سمات المدين ، ولكن أيضًا معلمات البنك (سعر الفائدة ، فترة التأخير المسموح بها) ، عندئذٍ يستحق إنشاء خدمة منفصلة تحتوي على الطريقة المناسبة.
وماذا يعني كل هذا؟
في سياق ما تقدم ، يمكننا تمييز خوارزمية بسيطة إلى حد ما تساعد على اتخاذ قرار ، ووضع الأسلوب في نموذج أو خدمة :
- إذا كانت الطريقة تستخدم خصائص النموذج فقط ، فينبغي الإعلان عنها في النموذج
- إذا كانت إحدى الطرق تستخدم ، في معظمها ، خصائص أحد النماذج وفقط جزئياً ، يمكن الإعلان عنها في النموذج
- إذا كانت الطريقة تستخدم بشكل موحد خصائص العديد من النماذج ، فمن المفيد نقلها إلى خدمة منفصلة أو موجودة
- إذا كانت إحدى الطرق تستخدم تبعية خارجية ، مثل المستودع ، فيجب نقلها إلى خدمة منفصلة أو موجودة
ملخص
لا يمكن أن ينظر إلى أنماط GRASP على أنها الحقيقة المطلقة. لكن يمكنهم أن يساعدوا في فهم أي كائن يعين هذا السلوك أو ذاك إليه بسهولة. تبعا لذلك ، فإن النزاع هو فقر الدم أو نموذج "الغنية" قد لا يكون له معنى ، حيث يتم اتخاذ القرار في كل حالة ، وهذا يتوقف على نموذج المجال الموضوع والسلوك المرتبط به. في عملية تصميم النظام ، سوف تظهر كل من الكيانات مع وبدون سلوك. وهذا صحيح تماما.