بناء مصنع مقابل Factory في .NET Framework

Question

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

هناك العديد من الحالات في الإطار حيث يمكنك الحصول على مثيل جديد من الهيكل أو الفصل دون استدعاء منشئته بنفسك. يحتوي فئة System.convertvert على مجموعة من الأساليب الثابتة التي تعمل مثل هذا. لتحويل عدد صحيح إلى منطقي، على سبيل المثال، يمكنك الاتصال بالتحويل. تعد قيمة الإرجاع الخاصة بهذه الطريقة هذه مجموعة منطقية جديدة إلى "True" إذا كان عدد صحيح غير صفر و "FALSE" خلاف ذلك. يقوم Convert Class بإنشاء المنطقي من أجل القيمة الصحيحة. أساليب تحويل النوع الأخرى تعمل بالمثل. يتم تعيين طرق التحليل على INT32 ومضاعفة مثيلات جديدة لهذه الكائنات إلى القيمة المناسبة مع توفر سلسلة فقط.

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

من: http://msdn.microsoft.com/en-us/magazine/cc188707.aspx..

Answer 1

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

يصبح نمط المصنع أكثر فائدة في .NET عند إنشاء فصول. على سبيل المثال، انظر إلى فئة WebRequest.

عادة ما تكون هذه الفئة مثيل لها عن طريق الاتصال:

WebRequest request = WebRequest.Create(url);

ال webrequest.create. الطريقة تستخدم نمط المصنع. اعتمادا على نوع URL، فإنه سيخلق نوعا مختلفا (فئة فرعية) من WebRequest. إذا مرت ذلك http:// عنوان URL، على سبيل المثال، سوف تنشئ فعليا httpwebrequest. مثيل - ftp:// عنوان URL سيخلق FTPWebRequest..

باستخدام نمط المصنع هنا، يمكن إضافة المزيد من أنواع URL لاحقا دون تغيير أي رمز على جانب العميل - أنت فقط تمر في عنوان URL المختلفة (كسلسلة)، والحصول على كائن جديد.

Answer 2

الفكرة كلها من المصنع تبدو مختلفة. لا يتعلق الأمر بالخياوض على تعقيد التنفيذ، فهو عن انقلاب الرقابة أيضا (IOC).

• بدلا من الخلق Sender و Receiver الأشياء الخاصة بك، دعونا نجعل MessageFactory الكائن المسؤول عن خلقها.
• دعونا نتخيل في البداية نفذنا TcpMessageFactory (MessageFactory السلل) خلق TcpSender و TcpReceiver أشياء. حتى الآن تطبيقنا يعمل مع TCP.
• لاحقا قليلا اكتشفنا أن UDP أسرع. لذلك نفذنا UdpSender و UdpReciever. وبعد علاوة على ذلك، نفذنا UdpMessageFactory (MessageFactory سليل كذلك)
• الآن يمكننا السماح للمستخدم باختيار البروتوكول الذي يجب استخدامه. بناء على هذا، نخلق كائن المصنع الخاص بنا (سواء TcpMessageFactory أو UdpMessageFactory) واستخدامها في طلبنا كذلك.

في هذا المثال MessageFactory.CreateSender و MessageFactory.CreateReciever يجب أن يكون طرق مجردة؛ طرق Sender & Reciever يجب أن يكون تشكيل واجهة برمجة التطبيقات العامة (عقد) مجردة أيضا.

BTW، تم استخدام المصانع في البداية بشكل أساسي لإنشاء كائن: تخيل مكتبة C ++ (DLL) التي يجب أن تسمح بإنشاء مجموعة من أنواعها الخاصة إلى .exe الرئيسية. تمرير المثيلات بين الوحدات المختلفة هناك مستحيل تقريبا، لأن هيكلهم يعتمد على مترجم معين. ولكن من الممكن اجتياز الواجهات. لذلك يجب أن يكون هذا DLL:

• تصدير وظيفة عودة واجهة مصنع، على سبيل المثال IDllTypeFactory
• الكائن ينفذ يجب أن يعود IDllTypeXxx أشياء على الاحتجاج CreateXxx طرق. هؤلاء IDllTypeXxx تنفذ بالفعل من قبل الأنواع التي خططناها في الأصل للتصدير.

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

Answer 3

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

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

في التطبيق الحالي، أنا بناء (مولد برنامج)، أحتاج إلى تحليل تعريف SQL DataTable. أنا أستخدم محلل طيور منزلية للقيام بذلك. في كل مرة يواجه المحلل فيها متغيرا ("نوع متغير المعرف")، أدعو المصنع وتمرير السلسلة إليه. ثم يقوم المصنع بعد ذلك بفحص فرعية متغيرة من النوع والعودة إلي sqlvariable., ، قد يكون ذلك في الواقع integersqlvariable. أو أ charsqlvariable..

كائن المحلل الرئيسي لا يعرف ما هو المتغير الذي حصلت عليه. يدفع SQLVariable إلى قائمة ويقرأ السطر التالي. بالطبع، يمكن أن يكون لدي فئة واحدة للتعامل مع جميع أنواع المتغير؛ أنا شخصيا اختر عدم القيام بذلك.

Answer 4

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

أعتقد أن الفكرة العامة للمقال تخفي التنفيذ بدلا من الوقاية بالضرورة من الحمل الزائد للمنشئة الضخمة من أجل حساب التغييرات المنشئ. لا ينبغي أن يكون للفكرة التي يجري الكائن معرفة كيف يمكن بناؤها.

في المثال المعطاة، لا تريد تسد فئة INT الخاصة بك مع كيفية تصبح int من سلسلة أو مضاعفة حتى تقوم بإنشاء مصنعك الوحيد الخاص بك هو إنشاء كائن X من المعلمات Y.

أود بالتأكيد أن أقترح كتاب أنماط التصميم الأول للرأس كإصلاحية جيدة لأنماط تصميم التعلم. الأمثلة مقرها Java ولكن المنطق وراءهم ينطبق بغض النظر عن اللغة التي تستخدمها.