قرار تصميم الفصل

Question

لدي معضلة صغيرة ربما يمكنك مساعدتي في حلها.

لقد كنت أعمل اليوم على تعديل عضوية ASP.NET لإضافة مستوى من المراوغة.في الأساس، تدعم عضوية ASP.NET المستخدمين والأدوار، مع ترك جميع قواعد التفويض لتعتمد على ما إذا كان المستخدم ينتمي إلى دور أم لا.

ما أحتاج إلى فعله هو إضافة مفهوم الوظيفة، حيث ينتمي المستخدم إلى دور (أو أدوار) وسيكون للدور وظيفة واحدة أو أكثر مرتبطة بها، مما يسمح لنا بتفويض إجراء محدد بناءً على ما إذا كان المستخدم ينتمي أم لا إلى الدور الذي لديه وظيفة معينة.

بعد قولي هذا، مشكلتي لا علاقة لها بها، إنها مشكلة تصميم فئة عامة.

أرغب في توفير طريقة مجردة في فئة رولي بروفيدر الأساسية الخاصة بي لإنشاء الوظيفة (واستمرارها)، ولكني أريد أن أجعلها اختيارية لحفظ وصف لهذه الوظيفة، لذلك أحتاج إلى إنشاء طريقة كريتيفونكشن الخاصة بي مع التحميل الزائد، واحد التوقيع بقبول الاسم، والآخر بقبول الاسم والوصف.

يمكنني التفكير في السيناريوهات التالية:

1. قم بإنشاء كلا التوقيعين باستخدام المعدل الملخص.هذه مشكلة تتمثل في أن المُنفِّذ قد لا يحترم أفضل الممارسات التي تنص على أن أحد التحميل الزائد يجب أن يستدعي الآخر مع تطبيع المعلمات، ويجب أن يكون المنطق فقط في الأخير (الذي يحتوي على جميع المعلمات).بالإضافة إلى ذلك، ليس من الجيد أن نطلب من المطور تنفيذ كلتا الطريقتين.

2. قم بإنشاء الأول مثل الظاهري، والثاني مثل الملخص.استدعاء الثاني من الأول، والسماح للمنفذ بتجاوز السلوك.لديها نفس المشكلة، يمكن للمنفذ اتخاذ "قرارات سيئة" عند تجاوزها.

3. كما كان من قبل، ولكن لا تسمح بتجاوز الأول (قم بإزالة المُعدِّل الافتراضي).تكمن المشكلة هنا في أن المُنفِّذ يجب أن يدرك أنه يمكن استدعاء الطريقة بوصف فارغ وعليه التعامل مع هذا الموقف.

أعتقد أن الخيار الأفضل هو الخيار الثالث..

كيف يتم التعامل مع هذا السيناريو بشكل عام؟عندما تقوم بتصميم فئة مجردة وتحتوي على أساليب مثقلة.ليس من غير المألوف على ما أعتقد ...

Answer 1

أشعر أن أفضل مزيج من DRYness وإجبار العقد هو كما يلي (في الكود الكاذب):

class Base {
  public final constructor(name) {
    constructor(name, null)
  end

  public abstract constructor(name, description);
}

أو بدلا من ذلك:

class Base {
  public abstract constructor(name);

  public final constructor(name, description) {
    constructor(name)
    this.set_description(description)
  }

  private final set_description(description) {
    ...
  }
}

هناك قاعدة في Java تدعم هذا القرار:"لا تستدعي أبدًا الأساليب غير النهائية من المنشئ."

Answer 2

للإجابة على الجزء الأول من رسالتك، قم بمراجعة AzMan (مدير التفويض)، والذي، بالمناسبة، مدمج في النوافذ.لديه القدرة على تحديد العمليات التي يمكن إعادة دمجها في الأدوار أو تعيينها مباشرة للمستخدمين.

الدفع

للإجابة على الجزء الثاني من سؤالك، لن أستخدم فئة الملخص.بدلاً من ذلك، ما عليك سوى توفير الوظيفة في المنشئ والانتهاء منها.يبدو أنك تريد السلوك المحدد، ولا تريد تغييره.لماذا يجبر المتحدرين على توفير التنفيذ.