سؤال

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

وهذا أمر سيئ.

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

وهذا امر جيد.

ولكن، يبدو أن يؤدي إلى وجود منخفض الدرجة التماسك . لم يعد هو ببساطة مسؤولة عن بالضبط ما تقوم به، ولكن كما أن لديها مندوبين أنه في المعنى، مما يجعل رمز أقل تماسكا من تكرار أجزاء من واجهة من وجوه المرتبطة به.

وهذا أمر سيئ.

هل يؤدي حقا في خفض التماسك؟ هل هو أهون الشرين؟

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

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

المحلول

وغرادي بوش في "وجوه المنحى تحليل وتصميم":

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

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

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

ويقول مارتن فاولر أنه سيكون أكثر راحة ووصفه بأنه "اقتراح ديميتر" (انظر المادة يسخر لا بذرة ):

و"اختبار Mockist لم يتحدث أكثر عن تفادي" حطام القطار "- سلاسل طريقة أسلوب getThis () getThat () getTheOther () تجنب وكما هو معروف على النحو التالي قانون ديميتر سلاسل الطريقة بينما سلاسل الطريقة هي... رائحة، المشكلة نقيض من الرجال في منتصف الكائنات المتضخمة مع طرق الشحن هو أيضا رائحة. (لقد شعرت دائما سأكون أكثر راحة مع قانون ديميتر لو كانت تسمى على اقتراح ديميتر ). "

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

نصائح أخرى

إذا كنت انتهاك قانون ديميتر من خلال وجود

int price = customer.getOrder().getPrice();

والحل هو عدم خلق getOrderPrice () وتحويل الشفرة في

int price = customer.getOrderPrice();

ولكن بدلا من أن نلاحظ أن هذا هو <وأ href = "https://stackoverflow.com/questions/114342/what-are-code-smells-what-is-the-best-way-to-correct- منهم "> كود رائحة وإجراء التغييرات ذات الصلة التي نأمل كلا زيادة التماسك وانخفاض اقتران. للأسف لا يوجد إعادة الهيكلية بسيط هنا ينطبق دائما، ولكن ربما يجب عليك تطبيق اقول لا نسأل

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

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

تأكد من عمل لك، لا تعمل لذلك.

وأنا لا أعرف إذا كان هذا يقلل فعلا التماسك.

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

لاطاعة القانون ديميتر في حالة مستويات متعددة من الاعتماد على الطبقة، تحتاج فقط إلى تطبيق التجميع / التركيب والتغليف جيدة في كل مستوى.

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

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

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