الفرق بين مبدأ المسؤولية الفردية وفصل المخاوف
https://stackoverflow.com/questions/1724469
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russianسؤال
ما الفرق بين مبدأ المسؤولية الفردية وفصل المخاوف؟
المحلول
مبدأ مسؤولية فردية (SRP) - إعطاء كل فئة مجرد سبب واحد للتغيير؛ و "سبب التغيير" == "المسؤولية". على سبيل المثال: فئة الفاتورة لا تتحمل مسؤولية طباعة نفسها.
فصل المخاوف (منذ عام 1974). القلق == ميزة النظام. رعاية كل مخاوف من الشواغل: بالنسبة لكل قلق، فإن المخاوف الأخرى غير ذات صلة. إخفاء تنفيذ السلوك.
من هنا.
نصائح أخرى
الفصل بين القلق مقابل مبدأ مسؤولية واحدة (SOC VS SRP)
من المقال المرتبط:
فصل المخاوف (SOC) - هل عملية كسر برنامج كمبيوتر في ميزات متميزة تتداخل في الوظائف بأقل قدر ممكن. القلق هو أي جزء من الفائدة أو التركيز في البرنامج. عادة، المخاوف مرادفة بالميزات أو السلوكيات.http://en.wikipedia.org/wiki/separation_of_concerns.
مبدأ مسؤولية واحدة (SRP) - يجب أن يكون لكل كائن مسؤولية واحدة، وأن جميع خدماتها يجب أن تتماشى بشكل ضئيل مع تلك المسؤولية. في بعض التماسك تعتبر مرادفا ل SRP.http://en.wikipedia.org/wiki/single_reponibonivity_principle.
تنص مسؤولية واحدة على أن كائن يكون مسؤولا عن وحدة واحدة من العمل.
تنص اندلاع المخاوف على أن التطبيقات يجب تقسيمها إلى الوحدات التي تتداخل وظيفتها بأقل قدر ممكن.
نتائج نهاية مماثلة ... تطبيقات مختلفة قليلا.
في رأيي مبدأ مسؤولية واحدة واحدة من الأدوات / التعابير لتحقيق فصل الشواغل.
مبدأ المسؤولية الفردية وفصل المخاوف هي حقا نفس الشيء.
من المؤكد أنك يمكن أن تعرض في مناقشة أكاديمية تحاول ندف نوع من الفرق بين الاثنين، ولكن لماذا؟ لجميع النوايا والأغراض التي تصف نفس الشيء. المشكلة الأكبر هي أن الناس يحصلون على الرغبة في معرفة بالضبط ما "القلق" و "المسؤولية"، أنهم ربما يفوتون الفكرة الهامة وراء SRP و Soc.
هذه الفكرة هي ببساطة تقسيم CodeBase إلى أجزاء معزولة مقرونة فضفاضة. يسمح ذلك للمطورين المتعددين بالعمل في أجزاء مختلفة دون التأثير على بعضهم البعض، كما يسمح أيضا بمطور واحد لتعديل جزء معزول واحد دون كسر آخر.
يتم تطبيق ذلك على مستوى الوحدة النمطية، على سبيل المثال MVC هو نمط معماري يعزز SRP و Soc. يتم تقسيم CodeBase إلى نماذج معزولة وآراء وحدات تحكم. وبهذه الطريقة يمكن إجراء تعديل الرأي بشكل مستقل عن النموذج. اثنين اثنين غير متشابكة بشكل مروع.
عند المستوى الأدنى، يجب تطبيق ذلك على الفصول الدراسية أيضا. بدلا من وضع العشرات من الأساليب في فئة واحدة، قم بتقسيم التعليمات البرمجية إلى عدة. لنفس الأسباب.
أيضا حتى على مستوى الأسلوب، انقسم طرق كبيرة إلى طرق أصغر.
في المبدأ. SRP هو مبدأ، وليس قاعدة، لذلك لا تضطر إلى (قراءة: لا ينبغي / لا ينبغي) اتبع ذلك دينيا إلى أقصى الحدود. هذا لا يعني الذهاب بعيدا وبعد طريقة سبع سبع فقط في كل فصل على سبيل المثال. هذا يعني فقط مبدأ عام لتقسيم الشفرة إلى أجزاء معزولة. النقطة هي أنها ستؤدي إلى أفضل رمز وأكثر استقرارا.
فصل المخاوف (SOC). قسم طلبك إلى ميزات متميزة مع التداخل قليلا في الوظيفة ممكنة. (مايكروسوفت).
"القلق" = "ميزة مميزة" = "قسم متميز"
"القلق" يعمل على مستويات عالية ومنخفضة
مبدأ مسؤولية واحدةتنص على أن كل وحدة أو فئة يجب أن تتحمل مسؤولية أكثر من جزء واحد من الوظيفة المقدمة من البرنامج، وينبغي أن تكون هذه المسؤولية مغلفة بالكامل من قبل الفصل. جميع خدماتها يجب أن تتماشى بشكل ضيق مع هذه المسؤولية. (تعريف ويكيبيديا)
"المسؤولية" = "سبب التغيير" تغيير ماذا؟ "جزء واحد من الوظيفة المقدمة من البرنامج" = الوحدة الأساسية
خاتمة
مبدأ مسؤولية واحدة يعمل على الوحدات الأساسية -> يعمل على مستوى منخفض
يعمل الفصل بين المخاوف على المستويات العالية والمنخفضة
SRP و SOC يعمل معا لفصل المخاوف. هم انهم
بالضبط نفس الشيء عند مستوى منخفض
فصل المخاوف هو عملية؛ مبدأ المسؤولية الفردية هي فلسفة التصميم / الهندسة المعمارية. إنهم ليسوا بعيدون تماما، لكنهم يخدمون أغراض مختلفة.
نظرا لأن أي من الإجابات السابقة اقتبس روبرت مارتن، الذي خلق مبدأ مسؤولية واحدة, أعتقد أن إجابة أكثر موثوقية هناك حاجة إلى هنا.
تم استخلاص إلهام مارتن ل SRP من David Parnas، Edsger Dijkstra (الذي صاغ المصطلح فصل المخاوف) لاري قسطنطين (الذي صاغ الشروط اقتران و تماسك). مارتن عزز أفكارهم في SRP.
صياغة أخرى لمبدأ المسؤولية الفردية هي:
اجتمع معا الأشياء التي تتغير لنفس الأسباب. افصل هذه الأشياء التي تتغير لأسباب مختلفة.
إذا كنت تفكر في ذلك، فسوف تدرك أن هذه مجرد طريقة أخرى لتحديد التماسك والاقتران. نريد زيادة التماسك بين الأشياء التي تتغير لنفس الأسباب، ونريد تقليل الاقتران بين الأشياء التي تتغير لأسباب مختلفة.
ومع ذلك، كما تفكر في هذا المبدأ، تذكر أن أسباب التغيير هي اشخاص. وبعد أنه اشخاص الذين يطلبون التغييرات. وأنت لا تريد الخلط بين هؤلاء الأشخاص، أو لنفسك، من خلال خلط التعليمات البرمجية التي يهتم بها العديد من الأشخاص الآخرين لأسباب مختلفة.
إلى السؤال الأصلي، والفرق البسيط بين SRP و Soc هو أن مارتن رفض المصطلح اهتمامات للإشارة إلى اشخاص.
مماثلة لكن: SOC مرتبط بالمخاوف: لكسر مشكلة معقدة في العديد من المخاوف، فإن SRP تتمثل في مسؤولية واحدة فقط.
SRP و SOC يعمل على مستوى مختلف من التجريد. الغرض هو في كلتا الحالتين للحد من اقتران وتعزيز التماسك. بينما يعمل SRP أكثر على مستوى كائن، قد يعمل SOC أيضا على تنفيذ مستوى الوظيفة. يمكن تنفيذ الوظيفة كائن واحد ولكن أيضا من خلال العديد من الكائنات. لذلك قد يختلف اقتران وتماسك كلا مبدأين.
حاولت رسم مقارنة بين الفصل بين المخاوف (SOC) ومبدأ مسؤولية واحدة (SRP).
اختلافات
SRP على مستوى الفصل، ولكن SOC موجود في كل برنامج كمبيوتر، أو التجريد ... أو في بعض الأحيان المستوى المعماري.
يدور SRP حول جودة (كيف لا) تقسيم نطاقك إلى فئات متماسكة لها مسؤولية واحدة فقط (سبب واحد للتغيير). في الجانب الآخر، SOC هو مبدأ تصميم لفصل سياق إلى أقسام متميزة، بحيث يتناول كل قسم مصدر قلق منفصل (ما ليس كذلك)، حيث يوجد الكثير من الأدوات (على سبيل المثال فئات، وظائف، وحدات، وحزم،. ..) للوصول إلى هذا الهدف مستويات مختلفة.
يعتمد مفهوم SRP على التماسك (التماسك العالي)، في حين أن Soc قريب من الجزيئة والتقسيم والقهر (D & C)، ... في كل مستوى من مستويات التجريد.
Soc هو مبدأ تصميم جيد للتعامل مع التعقيد، مثل التجريد، في حين أن الوصول إلى فصول مسؤولة واحدة، يمكنك استخدام مبدأ SOC كحل كبير. كما، طريقة لمعرفة أن الفئة لديها أكثر من مسؤولية واحدة إذا كنت تستطيع استخراج مسؤولية أخرى (قلق) من تلك الفئة.
التشابه
- بعد تطبيق كل من هذه المبادئ، يصبح سياقك أكثر قابلة لإعادة الاستخدام وصيانة وقوية وقابلة للقراءة، ....
إجابه:
فصل المخاوف (SOC) هو مصطلح أكثر تنوعا - يمكن تطبيقه على مستوى النظام أو عند مستويات أقل مثل الفصول الدراسية (أو حتى الأساليب داخل الفصل)
مبدأ مسؤولية واحدة (SRP) يستخدم لمناقشة SOC على المستويات السفلى على سبيل المثال في الفصل
طرق للتفكير في ذلك:
على المستوى المنخفض، لنادور SOC و SRP مرادفا. لذلك يمكنك أن تقول SRP مصطلح زائد - أو أنه ينبغي فقط استخدام SOC لمناقشة مستوى النظام
إعطاء (1)، مصطلح SOC غير غامض إلى حد ما. تحتاج إلى سياق لمعرفة ما إذا كانت المناقشة حول SOC رفيع المستوى أو المستوى الأدنى
لتذكر أن SRP هو المصطلح للمستويات المنخفضة فقط، فكر في ذلك: في اللغة اليومية، عادة ما يكون "المسؤولية" أمرا ما يمكن ربطه جيدا أنه يمكن ربطه بمزدئة محددة، في حين أن "المخاوف" عادة ما تكون غامضة تشمل مجموعة من الأشياء ذات الصلة، والذي ربما لماذا تناسب الفرعي أكثر طبيعية لمناقشة مستوى النظام أكثر من SRP
SOC في بعض الشعور أقوى كما يجب استخدام متطلبات / مبدأ SRP لأنه ينطبق على مستوى النظام، ويجب أن يتم تحقيقه حقا على مستوى النظام أيضا في تطوير مكونات النظام. وهذا يعني أن المستوى العالي من SOC يعني لائقة SOC / SRP على المستويات المنخفضة - ولكن العكس ليس صحيحا، أي المستوى الأدنى SOC / SRP لا يعني SOC أو أي شيء على الإطلاق إلى المستوى الأعلى التالي، لا يهمنا تشمل النظام. للحصول على مثال لشركة SOC / SRP التي تحققت على مستوى الطريقة، ولكن بعد ذلك انتهكت على مستوى الفصل، تحقق من هذا آخر بلوق أروسين.
