مبدأ المسؤولية الفردية: فئة ، سبب واحد فقط يسبب تغييره.
لماذا هناك حاجة إلى مبدأ المسؤولية الفردية؟
إذا كان لدى الفصل أسباب متعددة لتعديله ، فقد يؤدي تعديل وظيفة إلى حدوث أخطاء لوظائف أخرى ، لذلك من الأفضل أن تتحمل مسؤولية واحدة فقط عن الفصل. ولكن لا يزال من الصعب تحقيقه في التطبيقات العملية ، لذلك يمكننا فقط بذل قصارى جهدنا للامتثال لهذا المبدأ.
في بعض الأحيان ، سيواجه المطورون بعض المشكلات عند تصميم واجهات ، مثل خصائص المستخدم وسلوك المستخدم الذي يتم الإعلان عنه في واجهة. يؤدي هذا إلى تجميع كائن العمل والمنطق التجاري معًا ، مما يؤدي إلى وجود مسؤوليتين. مسؤوليات الواجهة غير واضحة ، ووفقًا لتعريف SRP ، فإنها تنتهك مبدأ المسؤوليات الفردية للواجهة.
هنا مثال:
حزمة com.loulijun.chapter1 ؛ الواجهة العامة itutu {// الارتفاع void setShengao (ارتفاع مزدوج) ؛ مزدوج getShengao () ؛ // وزن الفراغ settizhong (وزن مزدوج) ؛ مزدوج gettizhong () ؛ // Eat Boolean Chifan (Boolean Hungry) ؛ // على الإنترنت Boolean Shangwang (Boolean Silly) ؛ }المثال أعلاه لديه هذه المشكلة. ينتمي الطول والوزن إلى كائن العمل ، والطريقة المقابلة مسؤولة بشكل أساسي عن سمات المستخدم. إن تناول وتصفح الإنترنت هو منطق الأعمال المقابل ، وهو مسؤول بشكل أساسي عن سلوك المستخدم. لكن هذا سيمنح الناس شعورًا بأنهم لا يعرفون ما تفعله هذه الواجهة ، والمسؤوليات غير واضحة ، وستكون هناك مشكلات مختلفة أيضًا أثناء الصيانة اللاحقة.
الحل: مبدأ المسؤولية الفردية ، اقسم هذه الواجهة إلى واجهتين مع مسؤوليات مختلفة.
itutubo.java: مسؤول عن سمات Tutu (Tutu ، إذا كان اسمًا شخصيًا)
حزمة com.loulijun.chapter1 ؛ /*** BO: كائن العمل ، كائن العمل* المسؤول عن سمات المستخدم* Author Administrator**/public interface itutubo {// height void setshengao (ارتفاع مزدوج) ؛ مزدوج getShengao () ؛ // وزن الفراغ settizhong (وزن مزدوج) ؛ مزدوج gettizhong () ؛ }itutubl.java: مسؤول عن وضعه
حزمة com.loulijun.chapter1 ؛ /*** BL: منطق العمل ، منطق العمل* المسؤول عن سلوك المستخدم* Author Administrator**/public interface Itutubl {// eat a meal boolean chifan (boolean hungry) ؛ // Entertainment Boolean Shangwang (Boolean Silly) ؛ }هذا يدرك المسؤولية الفردية للواجهة. ثم عند تطبيق واجهة ، هناك فئتان مختلفتان
Tutubo.java
حزمة com.loulijun.chapter1 ؛ الفئة العامة توتوبو تنفذ itutubo {ارتفاع مزدوج الخاص ؛ وزن مزدوج خاص ؛ Override public double getShengao () {return height ؛ } Override public double gettizhong () {return weight ؛ } Override public void setShengao (ارتفاع مزدوج) {this.height = height ؛ } Override public void settizhong (وزن مزدوج) {this.weight = weight ؛ }}توتبل جافا
حزمة com.loulijun.chapter1 ؛ الطبقة العامة TUTUPR تنفذ itutubl {override boolean chifan (Boolean Hungry) {if (hungry) {system.out.println ("Go to Hot Pot ...") ؛ العودة صحيح. } إرجاع خطأ ؛ } Override Public Boolean Shangwang (Boolean Silly) {if (silly) {system.out.println ("مملة جدًا ، اذهب إلى الإنترنت ...") ؛ العودة صحيح. } إرجاع خطأ ؛ }}هذا يجعل الأمر واضحا. عندما تحتاج إلى تعديل سمات المستخدم ، تحتاج فقط إلى تعديل واجهة Itutubo ، والتي ستؤثر فقط على فئة Tutubo ولن تؤثر على الفئات الأخرى.
تلخيص:
1. الوضع الفعلي هو أنه في كثير من الأحيان لا يمكننا التنبؤ بـ "سبب التغيير" مقدمًا ، حتى نتمكن من بناء واجهتنا فقط بناءً على الخبرة ومحاولة التأكد من أن واجهة واحدة تتحمل مسؤولية واحدة فقط. ما نتحدث عنه هنا هو واجهات. قد ترث الفئات وتنفيذ واجهات متعددة ، مما يجعل من الصعب تحقيق مسؤولية واحدة.
2. عندما كانت الفصول التي كتبتها من قبل لديها أسباب متعددة للتغيير ، من الأفضل إعادة تشكيله.
ومع ذلك ، هناك مشكلة في مبدأ استخدام المسؤولية الفردية. لا يوجد معيار تقسيم واضح لـ "المسؤوليات". إذا تم تقسيم المسؤوليات مفصلة للغاية ، فسوف يؤدي ذلك إلى زيادة حادة في عدد الواجهات وفئات التنفيذ ، مما سيزيد من التعقيد ويقلل من قابلية الصيانة للرمز. لذلك ، عند استخدام هذه المسؤولية ، يجب علينا أيضًا تحليل الموقف المحدد. الاقتراح هو أن الواجهة يجب أن تتبنى مبدأ المسؤولية الفردية ، وإدراك مبدأ المسؤولية الفردية قدر الإمكان في تصميم الفصل. من الأفضل التسبب في تغييرات في الفصل إذا كان سبب أحد الأسباب.