ما هي اتفاقية التسمية التي تستخدمها لنمط الديكور؟ [مغلق

Question

لقد قمت مؤخرًا حقًا بحقن التبعية حقًا وعجب نمط تصميم الديكور وأستخدمه في كل مكان.

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

ماذا تفعل يا رفاق؟

Answer 1

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

في كل مرة تسمية سلسلة ، هل تضيف لاحقة سلسلة؟ يبدو لي مثل hgrnnotation ، وهذا شيء أحاول تجنبه.

Answer 2

خذ مثالاً من إطار IO الخاص بـ Java API. يستخدم نمط الديكور على نطاق واسع ولكن أسماء الفصول لا تعكس هذا. على سبيل المثال ، يجوز لزارع BufferredReader تزيين قائد FileReader ، لكن تم تسميته على اسم وظائفهم - القراء.

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

Answer 3

نسميها ما تفعله.

لدي مجموعة من الديكورات لواجهة iPrinter. انهم يسمى:

• PrintDisasterRecovery - معالجة الاستثناء
• printqueuer - يجعلها مكالمة غير متزامنة

ترث هذه الفصول من PrintDecorator ، لذلك إذا نظر شخص ما تحت الأغطية ، فيمكنهم رؤية ما يجري.

Answer 4

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