التعريف: قم بتغليف طلب في كائن ، مما يسمح لك بتعليم العميل باستخدام طلبات مختلفة أو طلبات قائمة انتظار أو سجلات طلب السجلات ، وتوفير وظائف إلغاء الأوامر واستردادها.
النوع: نمط سلوكي
مخطط الفصل:
هيكل وضع الأوامر
كما يوحي الاسم ، فإن وضع الأوامر هو تغليف الأوامر. أولاً ، دعونا نلقي نظرة على الهيكل الأساسي في مخطط فئة وضع الأوامر:
فئة الأوامر: فئة مجردة تعلن الأوامر التي يجب تنفيذها. بشكل عام ، يجب نشر طريقة التنفيذ للجمهور لتنفيذ الأمر.
Concretecommand فئة: فئة التنفيذ لفئة الأوامر ، تنفذ الأساليب المعلنة في الفئة المجردة.
فئة العميل: فئة الاتصال العميل النهائي.
يجب أن تكون وظائف الفئات الثلاثة أعلاه أسهل في الفهم. دعونا نركز على فئة invoker و recevier.
invoker Class: المتصل مسؤول عن استدعاء الأوامر.
فئة المتلقي: جهاز الاستقبال مسؤول عن استلام الأوامر وتنفيذها.
بعبارة صريحة ، فإن ما يسمى بتغليف الأوامر ليس أكثر من كتابة سلسلة من العمليات في طريقة ثم يطلق عليها العميل. ينعكس على الرسم البياني الفصل. لا يتطلب الأمر سوى فئة concretecommand وفئة العميل لإكمال تغليف الأوامر. حتى لو كان الأمر أبعد من ذلك ، من أجل زيادة المرونة ، يمكن إضافة فئة الأوامر للتجريد المناسب. ما هي وظيفة هذا المتصل والمستقبل؟
في الواقع ، يمكنك التفكير من منظور آخر: إذا قمت ببساطة بتغليف بعض العمليات كأمر للآخرين للاتصال بها ، فكيف يمكن تسمية نمط؟ كنموذج سلوكي ، يجب أن يحقق وضع الأوامر أولاً اقترانًا منخفضًا. فقط عندما تكون درجة الاقتران منخفضة يمكن تحسين المرونة. الغرض من إضافة أدوار المتصل والمستقبل هو بالضبط لهذا.
مثال:
تتضمن محاكاة تشغيل التلفزيون أوامر الطاقة والإغلاق والتغيير. الرمز كما يلي
// واجهة لتنفيذ أمر الواجهة العامة {void execute () ؛ }. public void turnon () {system.out.println ("televisino is on.") ؛ } public void tuttloff () {system.out.println ("التلفزيون هو OFF.") ؛ } public void changechannel (int channel) {this.currentChannel = Channel ؛ System.out.println ("قناة TV هي" + قناة +) ؛ }} // إيقاف تشغيل Command Concretecommand Public Commandon تنفذ الأمر {private tv mytv ؛ Public Commandon (TV TV) {mytv = tv ؛ } public void execute () {mytv.turnon () ؛ }} // إيقاف تشغيل Command Concretecommand Public Commandoff يبرز الأمر {private tv mytv ؛ commandoff / public (تلفزيون) {mytv = tv ؛ } public void execute () {mytv.turnoff () ؛ }} // command command command concretecommand public commandchange تنفذ الأمر {private tv mytv ؛ قناة int الخاصة ؛ commandchange public (TV TV ، int Channel) {mytv = tv ؛ this.channel = Channel ؛ } public void execute () {mytv.Changechannel (Channel) ؛ }} // يمكن اعتباره عنصر تحكم عن بعد Invoker Classe Public Control {Private Command OnCommand ، OffCommand ، ChangeChannel ؛ التحكم العام (أمر ON ، OFF ، قناة الأوامر) {onCommand = ON ؛ Offcommand = OFF ؛ ChangeChannel = Channel ؛ } public void turnon () {onCommand.execute () ؛ } public void tuttloff () {OffCommand.execute () ؛ } public void changechannel () {Changechannel.execute () ؛ }} // اختبار فئة الفئة العميل العميل العميل {public static void main (string [] args) {// command ulteiver receiver tv mytv = new tv () ؛ // command on command concretecommond on = new commandon (myTV) ؛ // command command commandoff concretecommond Off = commandoff new (myTV) ؛ . // Commun Control Object Control Control = New Control (On ، Off ، Channel) ؛ // power-on control.turnon () ؛ // Switch Channel Control.Changechannel () ؛ // أغلق Control.turnoff () ؛ }}نتائج التنفيذ
Televisino يعمل. الآن القناة التلفزيونية هي 2 ، التلفزيون متوقف.
مزايا وعيوب وضع الأوامر
بادئ ذي بدء ، يكون وضع الأوامر مغلفًا للغاية: يتم تغليف كل أمر ، وبالنسبة للعميل ، يتم تسمى الأمر المقابل بقدر ما هو مطلوب من الوظيفة دون معرفة كيفية تنفيذ الأمر. على سبيل المثال ، هناك مجموعة من أوامر تشغيل الملف: إنشاء ملف جديد ، ونسخ ملف ، وحذف ملف. إذا تم تغليف هذه العمليات الثلاثة في فئة الأوامر ، فيجب على العميل فقط معرفة أن هناك فئات الأوامر الثلاث هذه. أما بالنسبة للمنطق المغطى في فئة الأوامر ، فإن العميل لا يحتاج إلى معرفته.
ثانياً ، وضع الأوامر لديه قابلية جيدة. في وضع الأوامر ، فإن التغليف الأساسي للعمليات في فئة المتلقي ، وتغليف فئة الأوامر الثانوية لهذه العمليات الأساسية. عند إضافة أوامر جديدة ، فإن كتابة فئة الأوامر لا تكون عمومًا من نقطة الصفر. هناك عدد كبير من فئات المتلقي للاتصال ، وهناك أيضًا عدد كبير من فئات الأوامر للاتصال ، والرمز قابل لإعادة الاستخدام للغاية. على سبيل المثال ، في تشغيل ملف ، نحتاج إلى إضافة أمر لقطع ملف ، ونحن بحاجة فقط إلى الجمع بين أوامر نسخ ملف وحذف ملف ، وهو مريح للغاية.
أخيرًا ، دعنا نتحدث عن عيوب وضع الأوامر ، أي إذا كان هناك العديد من الأوامر ، فسيكون ذلك بمثابة صداع. لا سيما العديد من الأوامر البسيطة ليست سوى بضعة أسطر من التعليمات البرمجية التي يجب تنفيذها. إذا كنت تستخدم وضع الأوامر ، فلا داعي للقلق بشأن مدى بساطة الأمر ، فأنت بحاجة إلى كتابة فئة أوامر لتغليفه.
السيناريوهات المعمول بها لوضع الأوامر
بالنسبة لمعظم وظائف وضع الاستجابة للطلب ، فهي أكثر ملاءمة لاستخدام وضع الأوامر. كما يقول تعريف وضع الأوامر ، يكون وضع الأوامر أكثر ملاءمة لتنفيذ الوظائف مثل التسجيل والتراجع عن العمليات.
لخص
سواء كان استخدام الوضع في مناسبة هو سؤال متشابك للغاية لجميع المطورين. في بعض الأحيان ، نظرًا للتنبؤ ببعض التغييرات في المتطلبات ، يتم استخدام نمط تصميم معين لمرونة النظام وقابلية التوسع ، ولكن هذا الشرط المتوقع لا. على العكس من ذلك ، فقد جاءت العديد من المتطلبات غير المتوقعة ، مما أدى إلى استخدام نمط التصميم في لعب الدور المعاكس عند تعديل الكود ، بحيث اشتكى فريق المشروع بأكمله. أعتقد أن كل مبرمج واجه مثل هذا المثال. لذلك ، استنادًا إلى مبدأ التنمية الرشيقة ، عندما نتصميم برامج ، إذا استطعنا حلها جيدًا دون استخدام نمط معين وفقًا للاحتياجات الحالية ، فلا ينبغي لنا أن نقدمها ، لأنه ليس من الصعب تقديم نمط تصميم. يمكننا القيام بذلك على النظام عندما نحتاج حقًا إلى استخدامه وإدخال نمط التصميم هذا.
خذ وضع الأوامر كمثال. في تطورنا ، تكون وظيفة وضع الاستجابة للطلب شائعة جدًا. بشكل عام ، سنقوم بتغليف عملية الاستجابة للطلب في طريقة ما. يمكن تسمية هذه الطريقة المغطاة بأمر ، ولكن ليس وضع الأوامر. ما إذا كان ينبغي رفع هذا التصميم إلى ارتفاع النمط يجب النظر فيه بشكل منفصل ، لأنه إذا تم استخدام وضع الأوامر ، فيجب تقديم دور المتصل والمستقبل. المنطق الذي تم وضعه في الأصل في مكان واحد منتشرة إلى ثلاث فئات. عند التصميم ، من الضروري النظر فيما إذا كانت هذه التكلفة تستحق ذلك.