سؤال

أقوم حاليًا بتنفيذ نمط تصميم المصنع في بيثون ولدي بعض الأسئلة.

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

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

  3. أنا فقط أتساءل عما إذا كانت هناك طريقة معتادة لاستدعاء المصانع. على سبيل المثال ، أنا الآن أتصل بمصنع سيارتي كمركبات ، وبالتالي فإن الرموز ستذهب مثل المركبات. إنشاء (...). أرى الكثير من البرامج التعليمية التي تفعل ذلك مثل مركبة Factory ، لكنني أجدها طويلة جدًا ويفضل التنفيذ أيضًا.

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

شكرًا!

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

المحلول

  1. لا تعرض الفصل (على سبيل المثال اجعله خاصًا __MyClass, ، أو من الواضح أنك لا تريد استخدامها مباشرة _MyClass). بهذه الطريقة لا يمكن إنشاء مثيل لها إلا عبر وظيفة المصنع.
  2. ربما يجب عليك مراجعة استخدام وسيطات الكلمات الرئيسية ، والميراث. يبدو أنك قد تطل على هذه ، والتي ستقلل عمومًا من اعتمادك على المصانع المعقدة (لأكون صادقًا ، نادراً ما كنت بحاجة إلى مصانع).
  3. في بيثون ، لا يمكنك الحماية بسهولة من تعريض التنفيذ ، فإنه يتعارض مع زين بيثون. (إنها نفسها في أي لغة ، يمكن للفرد المصمم الحصول على ما يريده في النهاية). على الأكثر يجب أن تحاول التأكد من أن مستخدم الرمز الخاص بك لا عن طريق الخطأ افعل الشيء الخطأ ، ولكن لا يفترض أبدًا معرفة ما قد يقرره المستخدم النهائي تحقيقه باستخدام الكود الخاص بك. لا تجعل الأمر محشوًا ويصعب العمل معه.

نصائح أخرى

كن بيثوني. لا تفرط في تعقيد الكود الخاص بك مع حلول لغة "Enterprise" (مثل Java) التي تضيف مستويات غير ضرورية من التجريد.

يجب أن يكون الكود الخاص بك بسيطًا وبديهيًا. يجب ألا تحتاج إلى تفويض إلى فصل آخر لإنشاء إنشاء آخر.

هل هناك أي طريقة لمنع الاستئصال المباشر للفئات الخرسانية الفعلية؟

لماذا ا؟ هل المبرمجين الخاصين يشرون الذين يرفضون اتباع القواعد؟ إذا قدمت مصنعًا - ويقوم المصنع بما يحتاجه الناس - فسيستخدمون المصنع.

لا يمكنك "منع" أي شيء. تذكر. هذا بيثون - لديهم المصدر.

هل يجب علي استخدام مصنع للعميل لإنشاء النافذة ، فقط في حالة إضافة المزيد من أنواع النوافذ في المستقبل؟

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

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

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

أرى الكثير من البرامج التعليمية التي تفعل ذلك مثل مركبة Factory ، لكنني أجدها طويلة جدًا ويفضل التنفيذ أيضًا.

"طويل جدا"؟ يتم استخدامه نادراً ما لا يهم. استخدم أسماء طويلة - فهو يساعد الأشخاص الآخرين على فهم ما تفعله. هذا ليس رمز الجولف حيث يفوز عدد أقل من ضربات المفاتيح.

"يعرض التنفيذ"؟ أولاً ، لا يعرض شيئًا. ثانياً ، هذا بيثون - لديك كل المصدر في جميع الأوقات - كل شيء مكشوف بالفعل.

توقف عن التفكير كثيرًا في الوقاية والخصوصية. إنه ليس مفيدًا.

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