مرتبك بشأن مبدأ المسؤولية الفردية في المثال التالي

Question

في التالي فيديو, ، يأخذ المؤلف فئة حالية ويعين مبدأ المسؤولية الفردية لها. يأخذ فصل طباعة لديه وظيفة في الوصول إلى البيانات والتنسيق وطباعة التقرير. يقوم بتقسيم كل طريقة إلى فصله الخاص ، لذلك يقوم بإنشاء فئة DataAccess للتعامل مع الوصول إلى البيانات ، ويقوم بإنشاء فئة من التقارير للتعامل مع تنسيق التقرير ، ويقوم بإنشاء فئة ReportPrinter للتعامل مع طباعة التقرير. ثم يتم ترك فئة التقرير الأصلية بطريقة واحدة ، PRINT () التي تسمي طباعة طريقة فئة التقرير. يبدو أن DataAccess و ReportFormatter يتحملون مسؤولية ، لكن ReportPrinter يعتمد على DataAcess و ReportFormatter ، لذلك ألا يكسر هذا SRP أم أسيء فهمه؟

Answer 1

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

Answer 2

دون مشاهدة الفيديو ، يبدو أنه تصميم معقول. لا يتم كسر SRP ، حيث لا تظهر الطرق التي تتعامل مع الوصول إلى البيانات في فئة ReportPrinter ، فقط مفهوم "يمكنني الاتصال بشيء للحصول على البيانات التي أريدها".

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

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

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

Answer 3

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

Answer 4

لا. إنه لا يكسر SRP.

افترض أن

DataAccess implements IDataAccess    

ReportFormatter  implements IReportFormatter 

ReportPrinter implements IReportPrinter 

رغم أن ReportPrinter relies on DataAccess and ReportFormatter ، أي تغيير في عقد IDataAccess or IReportFormatter يجب تنفيذها بواسطة DataAccess and ReportFormatter على التوالى. ReportPrinter لا تقلق بشأن تغييرات المسؤولية في تلك الفئات.

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