كيف تذهب من سيء إلى جيد OOP التصميم ؟

Question

أنا أقرأ الكثير عن الممارسات الجيدة والسيئة في OOP التصميم.أنه من الجيد أن نعرف التصميم الخاص بك هو سيء أو جيد.ولكن كيف يمكنك الحصول على من سيء إلى التصميم الجيد ؟ لقد تقسيم واجهة (xaml) و codebehind من businesslogic الدرجة.آخر صف في تزايد كبير.لقد حاولت تقسيمه إلى أصغر دروس, ولكن أنا عالقة الآن.أي أفكار حول كيفية انقسام كبير الطبقات ؟ الطبقة الرئيسية 1 قائمة البيانات من أنواع مختلفة.أنا أفعل العمليات الحسابية على المجموع ، ولكن أيضا على أنواع الفردية.لدي طرق لإجراء هذه الحسابات والتي تسمى من الأحداث التعامل معها في codebehind.أي الأفكار إلى أين نذهب من هنا ؟

معلومات إضافية:

نحن بالفعل حوالي 6 أشهر في هذا المشروع.لقد عملت مع وجوه المنحى laguages لسنوات (أولا c++, java والآن c#), ولكن أبدا على مشروع كبير مثل هذا واحد.وأعتقد أننا حققنا بعض المنعطفات الخاطئة في البداية و أعتقد أننا بحاجة إلى تصحيح هذه.لا أستطيع تحديد أي تفاصيل عن هذا المشروع في الوقت الراهن.أنا ذاهب إلى أمر واحد أو كتابين حول التصميم.إذا كنت منفصلة كل الطبقات ، كيف يمكنني التمسك بها معا مرة أخرى ؟ ربما حتى أفضل من الاستمرار في هذا الطريق إلى الإصدار الأول و إعادة بناء أجزاء بعد أن لحظة الإفراج ؟

Answer 1

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

إذا كان هناك الكثير من الحسابات على أساس محتويات القائمة هل يعتبر نقل العمليات إلى تخصيص قائمة الصف ؟ نفس الأمر ينطبق على العمليات على أنواع محددة, ربما أنها يمكن أن تعيش داخل أنواع ؟

من حيث أداء مماثلة بعد العمليات المختلفة على أنواع مختلفة في النظر في استخدام الدولة نمط (انظر هذا كبديل عن التبديل البيانات) التي تمكنك من علاج الكيانات بطريقة موحدة.

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

Answer 2

الممارسة والقراءة.يكرر :)

بعض الكتب الموصى بها:

• الكود النظيف لروبرت سي مارتن
• أنماط تصميم GoF
• إعادة البناء بواسطة مارتن فاولر

أنا شخصياً أحببت أيضًا أنماط تصميم Head First، لكن النمط قد لا يكون مناسبًا للجميع.يوجد كتاب مشابه يسمى C# 3.0 Design Patterns (انظر ora.com).لديها الكثير من نفس الأشياء، ولكن بطريقة أكثر تقليدية.

Answer 3

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

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

يحرر:خذ هذا التفكير إلى مستوى "الطريقة" أيضًا - اجعل أساليبك مسؤولة عن شيء واحد، وشيء واحد فقط.يساعد على تقسيم الأساليب الكبيرة (> 50 سطرًا) بسرعة كبيرة إلى أجزاء من التعليمات البرمجية قابلة لإعادة الاستخدام.

Answer 4

غيّر طريقة تفكيرك في الأشياء.يجب أن يكون لكل كائن مسؤولية واحدة محددة للغاية.إذا كان لديك فصل دراسي يحمل اسمًا عامًا، مثل "MainBusinessLogic"، فمن المحتمل أنك تفعل شيئًا خاطئًا.

مكان عظيم للبدء:قراءة ديفيد ويست التفكير الكائني.

Answer 5

هذه مجرد إضافة لبعض اقتراحات الكتب الجيدة هنا.

كلما تحسنت في OO، كلما بدا لي أنني قمت بتقليل حجم الكائن.ليس الأمر وكأنني أتجه نحو جسم صغير الحجم أو أي شيء من هذا القبيل، ولكن يبدو أن هذا يحدث.

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

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

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

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

Answer 6

بالإضافة إلى توصية بريان الكود النظيف لروبرت سي مارتن, ، قد ترغب في قراءة "العم بوب" المبادئ الصلبة للتصميم الموجه للكائنات.

يمكنك سماعه وهو يتحدث عن المبادئ الصلبة هانسيلمينتس بودكاست 145 ورمز نظيف على صافي الصخور!عرض رقم 388.وهناك أيضا المزيد معه صافي الصخور!عرض رقم 410, ، لكن ما يتحدث عنه لا يرتبط حقًا بسؤالك، لقد قمت بإدراجه فقط في حالة استمتاعك بالسؤالين الأولين.

من بين ملفات البودكاست الثلاثة فضلت HanselMinutes.

Answer 7

إعادة بناء التعليمات البرمجية يعد كتاب مارتن فاولر كتابًا ممتازًا حول كيفية تغيير تصميم برنامجك دون كسره.

أنماط التصميم يعمل بشكل مشابه للخوارزميات ولكنه يخبرك بكيفية دمج الكائنات لأداء مهام مفيدة متنوعة.

أخيراً مارتن فاولر لديه مجموعة متنوعة من أنماط التصميم المفيدة للتطبيقات.على سبيل المثال عرض سلبي

Answer 8

مايكل فيذرز "العمل بفعالية مع التعليمات البرمجية القديمة" من المفترض أن تكون جيدة جدًا، لكني سأعترف أنني لم أقرأها بنفسي.

الشيء نفسه ينطبق على "إعادة البناء على الأنماط."

Answer 9

لقد وجدت أن العمل على "مهمة" معقدة دون مساعدة ومن ثم رؤية كيف يقوم شخص آخر بتنفيذها كانت تجربة تعليمية كبيرة بالنسبة لي.

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

Answer 10

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

في الأساس، نهجي هو الحصول على أقل عدد ممكن من الفصول الدراسية، ولكن ليس أقل.

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

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

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

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

ابتعد عن الأحداث والإشعارات إن أمكن، لأنها تحدث في نقاط زمنية وبالتالي تمثل تغييرات تدريجية في الحالة.سيكون عليك أن تشعر بالقلق الشديد بشأن احتمال إسقاطها أو تكرارها أو سوء ترتيبها.غالبًا ما يتم استخدامها بناءً على النظرية القائلة بأن أسلوب الاقتراع البسيط سيكون "أقل كفاءة" بينما يحدث العكس في كثير من الأحيان.

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

مجرد تصويتي السلبي ...

Answer 11

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

وجهات النظر للنظر فيها:

1. أتمتة اختبار جودة التصميم - ابحث عن الأدوات التي توفر مقاييس لجودة التصميم، كمراجعة لقرارات التصميم الخاصة بك.
2. قابلية اختبار الكود - هل تساعد أي من عمليات إعادة البناء لديك أو تعيق التطوير القائم على الاختبار أو كتابة اختبارات الوحدة أو كتابة الاختبارات الوظيفية؟ما مدى صعوبة اختبار أجزاء كبيرة من البنية بمجرد دمجها؟
3. التبرير - كيف تدافع عن هذه القرارات، سواء من CYA الساخر إلى الإدارة، والأهم من ذلك، حتى يؤمن فريقك بإعادة التصميم.يمكنك بسهولة وشرح باستمرار لماذا تم إجراء تغيير وهل سيكون من السهل العثور على هذا التفسير خلال 6 أشهر؟

التفضيلات الشخصية في التصميم، وخاصة إعادة البناء:

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

Answer 12

حاول كتابة المزيد من التعليمات البرمجية القابلة للاختبار، وهذا وحده أجبرني على البحث وتنفيذ ممارسات/مفاهيم تصميم OOP محسنة.