تصميم نمط للتنفيذ الافتراضي مع طرق فارغة

Question

هل هناك معين نمط التصميم يصف ذلك السيناريو حيث يتم توفير تطبيق افتراضي غير مجرون يقوم بتنفيذ جميع الطرق أو بعض الأساليب على الواجهة مع تطبيقات فارغة وغير مرئية. هذا يجري بموجب نية تهدئة فرعية مع عبء الأساليب المنفذة التي قد لا تحتاجها / استخدامها:

public interface MyInterface {
    public void doThis();
    public void doThat();
    public void done();
}

public class MyClass implements MyInterface {
    public void doThis() {
        // NO-OP
    }
    public void doThat() {
        // NO-OP
    }
    public void done() {
        // Some standard implementation
    }
}

public class MuSubClass extends MyClass {
    public void doThat() {
        // Subclass only cares about doThat()
    }
}

لقد رأيت هذا النمط استخدم عدة مرات بما في ذلك Java's Defaulthandler في Sax Framework, ، و موسمم. وبعد في حالات Somes، يتم تسمية مثل هذه الفصول كمحولات، لكنني كنت تحت الانطباع بأن نمط المحول يترجم بين واجهتين مختلفتين.

بالنظر إلى أنه في هذه الحالات، توجد واجهة واحدة معلنة فقط يتم ترجمتها إلى مجموعة فرعية غير محددة من تلك الواجهة - لست واضحا حول كيفية وجود هذا في روح نمط المحول.

علاوة على ذلك، لا أرى تماما كيف يلتزم هذا نمط nullobject. إما، بالنظر إلى أن بعض الطرق يمكن أن يكون لها تنفيذ، و Nullobject تقليديا Singleton.

Answer 1

لا توجد أنماط تصميم للتنفيذ الافتراضي.

أنا عادة يلدلع DoNothing بادئة إلى اسم الفصل. اعتمادا على نية أنا أستخدم أيضا Base أو Default (هذا الأخير يستخدم على نطاق واسع). المحتمل MouseAdapter يجب أن يسمى DefaultMouseListener.

في حال كنت تهتم، يمكنك كعب بواجهة بسيطة بسيطة DynamicProxy., ، يجب عليك إرجاع قيمة افتراضية "لطيفة" (NULL للكائن، 0 للأرقام، إلخ).

راجع للشغل هذا سؤال جيد للغاية.

تعديل

علاوة على ذلك، ليس كذلك كعب أو أ وهم: ربما يمكن الخلط بينها وبين كعب ولكن النية مختلفة.

Answer 2

لقد رأيت هذا التصميم المستخدمة في الربيع حيث لديهم فئة اسمه FlowExecutionListenerAdapter. الذي يحفظ عليك تنفيذ جميع عمليات FlowExecutionListener.

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

أنا متأكد من أن هذا السؤال قد طلب منه من قبل؟

هذا الأصوات مماثل رقم؟ قد يكون يستحق القراءة.

Answer 3

يستخدم أيضا في Swing (WindowAdapter، الذي ينفذ WindowListener). إنه فقط محول مريح، يجب عليك فقط تحديد أساليب 1-2 بهذه الطريقة للحصول على WindowListener مفيدة. هذا هو في الواقع مثيل لنمط المحول، ويظهر أيضا قوة الفئات المجردة. إنه حتى مثالا لتوضيح سبب وراثة التنفيذ المتعدد مفيدا في بعض الأحيان.

بالنسبة لأنماط التصميم العادية، في طريقة Temlate، يمكنك تحديد عمليات الخطافة، والتي قد تكون قديمة (على عكس الطرق المجردة، والتي يجب أن تكون)، ولكن السلوك الافتراضي (عادة لا يحتوي NO-OP) مفيد أيضا.

Answer 4

يجب عليك اتباع مبدأ التصميم المختلفة: مبدأ واجهة الفصل

ينص مبدأ فصل الواجهة على أنه لا ينبغي إجبار العملاء على تنفيذ واجهات لا يستخدمونها. بدلا من واجهة سمينة واحدة تفضل العديد من الواجهات الصغيرة على مجموعات من الطرق، كل واحد يخدم وحدة فرعية واحدة.

يجب عدم تطبيق المزيد ويجب عدم تطبيق أقل

إلقاء نظرة على أسئلة SE ذات الصلة لمزيد من التفاصيل.

مبدأ فصل واجهة

واجهة مبدأ الفصل - برنامج إلى واجهة

Answer 5

سؤال عظيم.

لقد بدأت في استخدام NoOp كادئة اسم الفصل لهذا النمط. انها قصيرة، واضحة، وغير مثقلة (مثل Empty لا يحتوي على شيء؟ Null نمط كائن فارغ، وهو مختلف؟]، Abstract هل يوفر بعض التنفيذ؟]، أو Base هل يوفر بعض التنفيذ؟]).

قد أكتب هذا النمط من الفصل عندما يكون لدي واجهة برمجة تطبيقات تابعة لجهة خارجية توفر "السنانير" للاكتترانية خلال عملية معقدة. النظر في الطبقتين التاليين المقدمة من مكتبة:

public class LongRunningActionRunner {
    public void runSomethingLong(DecisionListener cdh) {
        // ...
    }
}

public interface DecisionListener {
    public void beforeFooHook();
    public void afterFooHook();
    public void beforeBarHook();
    public void afterBarHook();
    public void beforeBazHook();
    public void afterBazHook();
}

في هذه الحالة، قد تصيب فئة باستخدام هذا النمط مثل هذا:

public class NoOpDecisionListener implements DecisionListener {
    @Override public Something beforeFooHook() {}
    @Override public Something afterFooHook() {}
    @Override public Something beforeBarHook() {}
    @Override public Something afterBarHook() {}
    @Override public Something beforeBazHook() {}
    @Override public Something afterBazHook() {}
}

Answer 6

كان هذا النمط منتشر في الإصدارات القديمة من جافا. انها جافا 7 بديل للطرق الافتراضية في واجهات.

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

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

Answer 7

لي هذا يبدو الأقرب إلى حالة خاصة أو كائن فارغ نمط.

تشير التحديثات الخاصة بك إلى شيء مشابه ل طريقة القالب نتوقع أنك لا تملك طريقة واحدة تستدعي كل طريقة قالب على سبيل المثال

public void doEverything()
{
  doThis();
  doThat();
  done();
}

Answer 8

هل تسأل عن نمط كائن فارغ?

مزيد من التحرير الخاص بك، MyClass الكائن ليس أكثر من الانحدار الافتراضي. لا أعتقد أن هناك أي نمط تصميم معين يصفه.

Answer 9

أعتقد أن مارتن فاولر سوف يسمي هذا نمط كائن فارغ. في كتابه Refactoring [1]، يقدم Martin أشياء فارغة على هذا النحو:

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

يضيف لاحقا، "أنت تستفيد عندما يريد العديد من العملاء أن يفعلوا نفس الشيء؛ يمكنهم ببساطة الاعتماد على السلوك الخالي الافتراضي." كما يقدم طريقة ISNULL () للعملاء الذين يتطلبون سلوكيات مختلفة.

أوافق على أن أرى في بعض الأحيان تنفيذ (مجردة في كثير من الأحيان) يسمى محول. على سبيل المثال، في إطار Android، AnimatorListenerAdapter. (مصدر الرمز هنا) يوصف بأنه:

توفر كل من فئة المحول تطبيقات فارغة من الطرق من Animator.AnimatorListener. يمكن لأي المستمع المخصص الذي يهتم فقط عن مجموعة فرعية من طرق هذا المستمع ببساطة فئة فئة محول هذا بدلا من تطبيق الواجهة مباشرة.

1] "إعادة المرجع: تحسين تصميم التعليمات البرمجية الموجودة،" الفصل 9، "تبسيط التعبيرات المشروطة،" "إدخال كائن فارغ".