23 أوضاع التصميم ، الفصل 17: وضع أوامر Java
التعريف: قم بتغليف طلب في كائن ، مما يسمح لك بتعليم العميل باستخدام طلبات مختلفة أو طلبات قائمة انتظار أو سجلات طلب السجلات ، وتوفير وظائف إلغاء الأوامر واستردادها.
النوع: نمط سلوكي
مخطط الفصل:
هيكل وضع الأوامر
كما يوحي الاسم ، فإن وضع الأوامر هو تغليف الأوامر. أولاً ، دعونا نلقي نظرة على الهيكل الأساسي في مخطط فئة وضع الأوامر:
فئة الأوامر: فئة مجردة تعلن الأوامر التي يجب تنفيذها. بشكل عام ، يجب نشر طريقة التنفيذ للجمهور لتنفيذ الأمر.
Concretecommand فئة: فئة التنفيذ لفئة الأوامر ، تنفذ الأساليب المعلنة في الفئة المجردة.
فئة العميل: فئة الاتصال العميل النهائي.
يجب أن تكون وظائف الفئات الثلاثة أعلاه أسهل في الفهم. دعونا نركز على فئة invoker و recevier.
invoker Class: المتصل مسؤول عن استدعاء الأوامر.
فئة المتلقي: جهاز الاستقبال مسؤول عن استلام الأوامر وتنفيذها.
بعبارة صريحة ، فإن ما يسمى بتغليف الأوامر ليس أكثر من كتابة سلسلة من العمليات في طريقة ثم يطلق عليها العميل. ينعكس على الرسم البياني الفصل. لا يتطلب الأمر سوى فئة concretecommand وفئة العميل لإكمال تغليف الأوامر. حتى لو كان الأمر أبعد من ذلك ، من أجل زيادة المرونة ، يمكن إضافة فئة الأوامر للتجريد المناسب. ما هي وظيفة هذا المتصل والمستقبل؟
في الواقع ، يمكنك التفكير من منظور آخر: إذا قمت ببساطة بتغليف بعض العمليات كأمر للآخرين للاتصال بها ، فكيف يمكن تسمية نمط؟ كنموذج سلوكي ، يجب أن يحقق وضع الأوامر أولاً اقترانًا منخفضًا. فقط عندما تكون درجة الاقتران منخفضة يمكن تحسين المرونة. الغرض من إضافة أدوار المتصل والمستقبل هو بالضبط لهذا. الرمز العام لوضع الأوامر هو كما يلي:
Class Invoker {private command ؛ public void setCommand (command command) {this.command = command ؛ } public void Action () {this.command.execute () ؛ }} command classe {public Abstract void execute () ؛ } class concretecommand يمتد الأمر {استقبال المتلقي الخاص ؛ concretecommand (جهاز الاستقبال المتلقي) {this.receiver = جهاز الاستقبال ؛ } public void execute () {this.receiver.dosomething () ؛ }} class receiver {public void dosomething () {system.out.println ("معالجة منطق المتلقي--Business") ؛ }} client client {public static void main (string [] args) {receiver receiver = new receiver () ؛ الأمر أمر = concretecommand جديد (جهاز الاستقبال) ؛ // ينفذ العميل مباشرة طريقة الأمر المحدد (هذه الطريقة تتفق مع مخطط الفئة). execute () ؛ // يقوم العميل بتنفيذ الأمر من خلال المتصل invoker invoker = جديد invoker () ؛ invoker.setCommand (command) ؛ invoker.action () ؛ }}من خلال الكود ، يمكننا أن نرى أنه عندما ندعو ، يكون توقيت التنفيذ هو أولاً فئة المتصل ، ثم فئة الأوامر ، وأخيراً فئة المتلقي. بمعنى آخر ، ينقسم تنفيذ الأمر إلى ثلاث خطوات ، ودرجة الاقتران أقل بكثير من تغطية جميع العمليات في فئة. هذا هو جوهر نمط الأوامر: افصل المتصل في الأمر والمنفذ بحيث لا يتعين على الطرفين الاهتمام بكيفية عمل الطرف الآخر.
مزايا وعيوب وضع الأوامر
بادئ ذي بدء ، يكون وضع الأوامر مغلفًا للغاية: يتم تغليف كل أمر ، وبالنسبة للعميل ، يتم تسمى الأمر المقابل بقدر ما هو مطلوب من الوظيفة دون معرفة كيفية تنفيذ الأمر. على سبيل المثال ، هناك مجموعة من أوامر تشغيل الملف: إنشاء ملف جديد ، ونسخ ملف ، وحذف ملف. إذا تم تغليف هذه العمليات الثلاثة في فئة الأوامر ، فيجب على العميل فقط معرفة أن هناك فئات الأوامر الثلاث هذه. أما بالنسبة للمنطق المغطى في فئة الأوامر ، فإن العميل لا يحتاج إلى معرفته.
ثانياً ، وضع الأوامر لديه قابلية جيدة. في وضع الأوامر ، فإن التغليف الأساسي للعمليات في فئة المتلقي ، وتغليف فئة الأوامر الثانوية لهذه العمليات الأساسية. عند إضافة أوامر جديدة ، فإن كتابة فئة الأوامر لا تكون عمومًا من نقطة الصفر. هناك عدد كبير من فئات المتلقي للاتصال ، وهناك أيضًا عدد كبير من فئات الأوامر للاتصال ، والرمز قابل لإعادة الاستخدام للغاية. على سبيل المثال ، في تشغيل ملف ، نحتاج إلى إضافة أمر لقطع ملف ، ونحن بحاجة فقط إلى الجمع بين أوامر نسخ ملف وحذف ملف ، وهو مريح للغاية.
أخيرًا ، دعنا نتحدث عن عيوب وضع الأوامر ، أي إذا كان هناك العديد من الأوامر ، فسيكون ذلك بمثابة صداع. لا سيما العديد من الأوامر البسيطة ليست سوى بضعة أسطر من التعليمات البرمجية التي يجب تنفيذها. إذا كنت تستخدم وضع الأوامر ، فلا داعي للقلق بشأن مدى بساطة الأمر ، فأنت بحاجة إلى كتابة فئة أوامر لتغليفه.
السيناريوهات المعمول بها لوضع الأوامر
بالنسبة لمعظم وظائف وضع الاستجابة للطلب ، فهي أكثر ملاءمة لاستخدام وضع الأوامر. كما يقول تعريف وضع الأوامر ، يكون وضع الأوامر أكثر ملاءمة لتنفيذ الوظائف مثل التسجيل والتراجع عن العمليات.
لخص
سواء كان استخدام الوضع في مناسبة هو سؤال متشابك للغاية لجميع المطورين. في بعض الأحيان ، نظرًا للتنبؤ ببعض التغييرات في المتطلبات ، يتم استخدام نمط تصميم معين لمرونة النظام وقابلية التوسع ، ولكن هذا الشرط المتوقع لا. على العكس من ذلك ، فقد جاءت العديد من المتطلبات غير المتوقعة ، مما أدى إلى استخدام نمط التصميم في لعب الدور المعاكس عند تعديل الكود ، بحيث اشتكى فريق المشروع بأكمله. أعتقد أن كل مبرمج واجه مثل هذا المثال. لذلك ، استنادًا إلى مبدأ التنمية الرشيقة ، عندما نتصميم برامج ، إذا استطعنا حلها جيدًا دون استخدام نمط معين وفقًا للاحتياجات الحالية ، فلا ينبغي لنا أن نقدمها ، لأنه ليس من الصعب تقديم نمط تصميم. يمكننا القيام بذلك على النظام عندما نحتاج حقًا إلى استخدامه وإدخال نمط التصميم هذا.
خذ وضع الأوامر كمثال. في تطورنا ، تكون وظيفة وضع الاستجابة للطلب شائعة جدًا. بشكل عام ، سنقوم بتغليف عملية الاستجابة للطلب في طريقة ما. يمكن تسمية هذه الطريقة المغطاة بأمر ، ولكن ليس وضع الأوامر. ما إذا كان ينبغي رفع هذا التصميم إلى ارتفاع النمط يجب النظر فيه بشكل منفصل ، لأنه إذا تم استخدام وضع الأوامر ، فيجب تقديم دور المتصل والمستقبل. المنطق الذي تم وضعه في الأصل في مكان واحد منتشرة إلى ثلاث فئات. عند التصميم ، من الضروري النظر فيما إذا كانت هذه التكلفة تستحق ذلك.
ما سبق هو كل محتوى هذه المقالة. آمل أن يكون ذلك مفيدًا لتعلم الجميع وآمل أن يدعم الجميع wulin.com أكثر.