سؤال

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

http://www.jroller.com/landers/entry/the_design_pattern_facade_pattern

هل هذه رائحة التصميم؟هل يجب أن أفرض حدًا على هذا الرقم؟

أعلم أن بعض المبرمجين لديهم قواعد مماثلة لأشياء أخرى (على سبيل المثال.ما لا يزيد عن N من مستويات عدم اتجاه المؤشر في C.)

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

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

المحلول

أنا أراها كرائحة تصميمية - ستجعلني أفكر إذا كانت كل هذه المستويات من التجريد تسحب وزنًا كافيًا.

لا أستطيع أن أفهم سبب رغبتك في تسمية الفصل "InstructionBuilderFactoryMapFactory"؟هل هناك أنواع أخرى من المصانع - شيء لا ينشئ InstructionBuilderFactoryMap؟أم أن هناك أي أنواع أخرى من InstructionBuildersFactory التي تحتاج إلى تعيينها؟

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

نصائح أخرى

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

لا يبدو اسم الفئة سيئًا فحسب، بل لا يخبرنا شيئًا عما يفعله.يعتمد اسمها على تنفيذها وبنيتها الداخلية.

نادرًا ما أستخدم اسم النمط في الفصل الدراسي، باستثناء (أحيانًا) المصانع.

يحرر:

وجدت مثيرة للاهتمام شرط حول التسمية في Coding Horror، يرجى التحقق من ذلك!

من المؤكد أن الكثير من الأنماط في اسم الفئة هي رائحة، لكن الرائحة ليست مؤشرًا محددًا.إنها إشارة "للتوقف لمدة دقيقة وإعادة التفكير في التصميم".في كثير من الأحيان عندما تجلس وتفكر في أن الحل الأكثر وضوحًا يصبح واضحًا.في بعض الأحيان، بسبب القيود الموجودة (الفنية/الوقت/الطاقة البشرية/إلخ) يعني أنه يجب تجاهل الرائحة في الوقت الحالي.

أما بالنسبة للمثال المحدد، فلا أعتقد أن الاقتراحات الواردة من معرض الفول السوداني فكرة جيدة دون مزيد من السياق.

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

ParserBuilderFactoryImpl(ParserFactory psF) {
...
}

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

الآن، ما هو h..l ParserFactory؟آه، أنا سعيد لأنك سألت!من أجل اختبار تطبيق منشئ المحلل اللغوي، أحتاج إلى استدعاء طريقته ثم معرفة نوع المحلل اللغوي الذي تم إنشاؤه.الطريقة الوحيدة للقيام بذلك دون كسر تغليف فئة المحلل اللغوي المعينة التي يقوم المنشئ بإنشائها هي وضع نقطة اعتراض مباشرة قبل إنشاء المحلل اللغوي، لمعرفة ما يدخل إلى مُنشئه.ومن ثم ParserFactory.إنها مجرد طريقة بالنسبة لي لملاحظة ما يتم تمريره إلى مُنشئ المحلل اللغوي في اختبار الوحدة.

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

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