سؤال

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

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

ما هو دليل التحديدات ما إذا كنت تريد استخدام نمط أو الآخر؟

هل كانت مفيدة؟

المحلول

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

أولاً ، يسرد التسلسل الهرمي النطاق الذي ينطبق عليه نمط معين ، أو النمط المناسب لاستخدامه لتغليف مستوى من التفاصيل ، اعتمادًا على جانب الجدول الذي تبدأ فيه.

design pattern encapsulation hierarchy table

كما ترون من الجدول ، يخفي كائن نمط الإستراتيجية تفاصيل تطبيق الخوارزمية ، وبالتالي فإن استخدام كائن استراتيجي مختلف سيؤدي نفس الوظيفة ولكن بطريقة مختلفة. قد يتم تحسين كل كائن استراتيجية لعامل معين أو يعمل على معلمة أخرى ؛ ومن خلال استخدام واجهة مشتركة ، يمكن للسياق أن يعمل بأمان مع أي منهما.

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

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

نصائح أخرى

الاستراتيجيات تغلف الخوارزميات. أوامر افصل المرسل عن مستقبل الطلب ، حيث يقومون بتحويل طلب إلى كائن.

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

الإجابة على سؤال قديم جدا. (هل يرى أي شخص أحدث إجابات بدلاً من أكثر من أكثر من التصويت؟)

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

الفرق الرئيسي هو الفهم ماذا او ما مغلف. مبدأ OO ، كلا النموذجين يعتمدون عليه ، هو تغليف ما يختلف.

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

في حالة الأمر ، ما يختلف هو طلب بحد ذاتها. قد يأتي الطلب من File Menu > Delete أو Right Click > Context Menu > Delete أو Just Delete Button pressed. يمكن لجميع الحالات الثلاث إنشاء 3 كائنات أمر من نفس النوع. تمثل كائنات الأوامر هذه فقط 3 طلبات للحذف ؛ لا حذف خوارزمية. نظرًا لأن الطلبات هي مجموعة من الكائنات الآن ، يمكننا إدارتها بسهولة. فجأة أصبح من التافهة توفير وظائف مثل التراجع أو إعادة.

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

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

أعتقد أن الأمر يساعدنا على توسيع فهمنا للتغليف بينما توفر الإستراتيجية الاستخدام الطبيعي للتغليف وتعدد الأشكال.

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

ربما جرب أولاً استراتيجية ، إذا لم تكن النتائج جيدة بما يكفي ، فحاول الاستراتيجية two ...

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

علامة

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

  • ترتبط جميع الأزرار على شريط أدوات التطبيق ببعض الإجراءات.
  • الزر هو المنفذ في هذه الحالة.
  • الإجراء هو الأمر في هذه الحالة.

عادة ما يكون الأمر محدودًا لبعض المجال أو منطقة العمل ، ولكن ليس ضروريًا: قد يكون لديك أوامر تصدر فاتورة أو بدء صاروخ أو إزالة ملف ينفذ نفس الواجهة (على سبيل المثال Single execute() الطريقة) ضمن تطبيق واحد. غالبًا ما تكون الأوامر ملائمة للذات ، لذلك لا يحتاجون إلى أي شيء من المنفذ لمعالجة المهمة التي يعتزمونها (يتم تقديم جميع المعلومات اللازمة في وقت البناء) ، وأحيانًا تكون الأوامر حساسة للسياق وينبغي أن تكون قادرة على اكتشاف هذا السياق ((المساحة الخلفية يجب أن يعرف الأمر موضع الذبابة في النص لإزالة الحرف السابق بشكل صحيح ؛ التراجع يجب أن يكتشف الأمر المعاملة الحالية للتراجع ؛ ...).

ال إستراتيجية مختلف بعض الشيء: إنه أكثر ملزمة لبعض المناطق. قد تحدد الإستراتيجية قاعدة لتنسيق تاريخ (في UTC؟ محددة المحددة؟) (استراتيجية "التنسيق") أو لحساب مربع للشخصية الهندسية (استراتيجية "الحاسبة المربعة"). الاستراتيجيات هي في هذا المعنى كائنات وزن الذبابة ، والتي تأخذ شيئًا كمدخلات ("التاريخ" ، "الشكل" ، ...) واتخاذ بعض القرارات على أساسها. ربما ليس الأفضل ، ولكن مثال جيد على الاستراتيجية هو واحد مرتبط به javax.xml.transform.Source الواجهة: اعتمادًا على ما إذا كان الكائن الذي تم تمريره هو DOMSource أو SAXSource أو StreamSource ستطبق الاستراتيجية (= محول XSLT في هذه الحالة) قواعد مختلفة لمعالجتها. يمكن أن يكون التنفيذ بسيطًا switch أو تنطوي سلسلة مسؤولية نمط المسؤولية.

ولكن في الواقع ، هناك شيء مشترك بين هذين النموذجين: الأوامر والاستراتيجيات تغلف خوارزميات داخل نفس المنطقة الدلالية.

يأمر:

المكونات الأساسية:

  1. يأمر يعلن عن واجهة لأوامر مجردة مثل execute()
  2. المتلقي يعرف كيفية تنفيذ أمر معين
  3. invoker يحمل concretecommand, ، والتي يجب تنفيذها
  4. عميل يخلق concretecommand وتعيين المتلقي
  5. concretecommand يحدد الربط بين يأمر و المتلقي

سير العمل:

عميل المكالمات invoker => invoker المكالمات concretecommand => concretecommand المكالمات المتلقي الطريقة التي تنفذ مجردة يأمر طريقة.

ميزة : العميل لا يتأثر التغييرات في الأمر والمستقبل. invoker توفير اقتران فضفاض بين العميل والمستقبل. يمكنك تشغيل أوامر متعددة مع نفس invoker.

يأمر يسمح لك النمط بتنفيذ أمر مختلف أجهزة الاستقبال باستخدام نفسه invoker. Invoker غير مدرك لنوع من المتلقي

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

يمكنك استخدام يأمر نمط ل

  1. تفوق على invoker ومستقبل القيادة

  2. تنفيذ آلية رد الاتصال

  3. تنفيذ التراجع وإعادة وظيفة

  4. الحفاظ على تاريخ الأوامر

java.lang.Thread هو تنفيذ جيد ل يأمر نمط. يمكنك علاج خيط كما invoker وتنفيذ الفصل Runnable كما concretecommonad/جهاز الاستقبال و run() طريقة يأمر.

يمكن قراءة إصدار/إعادة نمط الأوامر في ثيودور نورفيل مقالة - سلعة

إستراتيجية:

نمط الإستراتيجية بسيط للغاية لفهمه. استخدم هذا النمط متى

لديك تطبيقات متعددة لخوارزمية ويمكن أن يتغير تنفيذ الخوارزمية في وقت التشغيل اعتمادًا على شروط معينة.

أخذ مثالا على مكون أجرة نظام حجز الخطوط الجوية

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

الوجبات الرئيسية من إستراتيجية نمط:

  1. إنه نمط سلوكي
  2. إنه يعتمد على التفويض
  3. يغير الشجاعة من الكائن عن طريق تعديل سلوك الطريقة
  4. يتم استخدامه للتبديل بين عائلة الخوارزميات
  5. يغير سلوك الكائن في وقت التشغيل

المشاركات ذات الصلة مع أمثلة رمز:

باستخدام نمط تصميم الأوامر

مثال في العالم الحقيقي لنمط الاستراتيجية

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

  • للحصول على استراتيجية ، يعرف المكون باستخدام الكائن ماذا او ما الكائن يفعل (وسيستخدمه لأداء جزء من عمله) ، لكنه لا يهتم كيف يفعل ذلك.

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

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

مرخصة بموجب: CC-BY-SA مع الإسناد
لا تنتمي إلى StackOverflow
scroll top