سؤال

سمعت مؤخرا أن هناك 9 قواعد ل Oop (Java). أعرف فقط أربعة فقط من التجريد، تعدد الأشكال، الميراث والتغليف. هل هناك أي قواعد أخرى ل OOP؟

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

المحلول

يبدو وكأنه ما تبحث عنه مبادئ التصميم الموجه للكائن.

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

SRP مبدأ المسؤولية الفردية يجب أن يكون للفئة سببا واحدا فقط للتغيير.

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

LSP مبدأ بدائل LISKOV يجب أن تكون الفرعية للبديل لأنواعها الأساسية.

تراجع مبدأ انعكاس التبعية يجب أن تعتمد التجراج على التفاصيل. يجب أن تعتمد التفاصيل upons تجريدات.

ISP مبدأ فصل واجهةلا يجبر العملاء Shold على الاعتماد على الأساليب التي لا يستخدمونها. واجهات تنتمي إلى العملاء، وليس التسلسلات الهرمية.

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

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

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

ADP مبدأ التبعيات acylcicاسمح أي دورات في الرسم البياني التبعية.

SDP مبدأ التبعيات المستقرتعتمد في اتجاه الاستقرار.

SAP مبدأ التجريدات المستقرةيجب أن تكون الحزمة مجردة لأنها مستقرة.

نصائح أخرى

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

  • فصل القلق
  • مسؤولية واحدة لكل فصل
  • تفضل التركيب على الميراث
  • البرمجة إلى الواجهة
  • بالإضافة إلى كل ما ذكره Billybob، بالفعل

هذه المبادئ OO مستقيمة من رأس أنماط التصميم الأول:

  • تغليف ما يختلف
  • برنامج إلى واجهة، بدلا من التنفيذ
  • تأييد التركيب على الميراث
  • يجب أن يكون للفئة سببا واحدا فقط للتغيير (مبدأ مسؤولية واحدة)
  • يجب أن تكون الأنواع الفرعية محل استبدالها لقاعدتهم (مبدأ استبدال Liskov.)
  • فصول shoule تكون مفتوحة للتمديد، ولكنها مغلقة للتعديل (مبدأ مفتوح مغلقة)

هذه هي المفاهيم، وليس القواعد. لا توجد قواعد حقا، فقط قرارات لجعلها، بعض التصاميم أفضل من غيرها، بعضها أفضل بكثير من الآخرين :-)

هناك الكثير من المبادئ التوجيهية رغم ذلك :-) بعضها هي لغة محددة (C ++ مليئة بهم) الآخرين هي محددة. الكثير إلى القائمة على الرغم من :-)

خارج الجزء العلوي من رأسي، والأهمية هي:

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

الكثير لتوسيع وإضافة :-)

تحرير: يجب أن أضيف، والقواعد التي تدرجها ليست فريدة من نوعها

وفقا للمبرمجين البراغماتيون - القواعد هي:

  • اجعله يجف (لا تكرر نفسك)
  • اجعلها خجولة (تأكد من أن فصولك لها تماسك مرتفع وانخفاض اقتران)
  • وأخبر الرجل الآخر (فصل المخاوف)

http://media.pragprog.com/articles/may_04_oo1.pdf.

لا توجد "قواعد" ل OOP.

هناك 4 خصائص لغة تجعل جسمك موجه نحو كائن أو لا (هذه هي الأشياء التي أدرجتها في سؤالك).

بقية المواد هناك إرشادات. المبادئ التوجيهية الأفضل / الأكثر فائدة قرأتها يمسك

العديد من الاقتراحات غير مفهومة بسهولة من قبل Laymen (التخصصات غير المرفوعة). اعتقدت أن فهم كان براغماتي ودود.

أعتقد أن فهم جميل لأنه يقترح الجزء الأكثر أهمية من OO باسمه - تعيين المسؤولية (إلى الكائنات وليس المبرمجين).

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

راجع للشغل - هل أتقابلك فقط؟ قمت بنسخ السؤال بشكل غير صحيح ...

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