单一责任原则是OOP的规则吗？ [英] Is Single Responsibility Principle a rule of OOP?

问题描述

一个回答到堆栈溢出问题表示，一个特定的框架违反了简单和简单的OOP规则：单一责任原则（SRP）。

单一责任原则真的 OOP的规则？

我对面向对象编程定义的理解是对象及其行为用于创建软件的范例。这包括以下技术：封装，多态和继承。

现在不要误会我 - 相信SRP是最好的OO设计的关键，但我觉得有些情况下这个原则可以和应该被破坏（就像数据库规范化规则）。我积极推动SRP的好处，我的大部分代码遵循这一原则。

但是，这是否是一个规则，因此意味着不应该被破坏？

解决方案

在软件开发中，很少的规则（如果有的话）也是无一例外的。有些人认为没有地方可以使用，但是错误。

就OOP而言，没有一个面向对象的定义，所以根据你所问的人，你会得到一套不同的硬，软原则，模式和做法。

OOP的经典想法是将消息发送到其他不透明对象，并且对象使用自己内部的知识解释消息，然后执行某种功能。

SRP是一种软件工程原理，可以应用于类，功能或模块的作用。它有助于一些东西的凝聚力，使它的行为很好地放在一起，没有无关的位悬在其上，或者有多个角色交织在一起，使事情变得复杂。

即使只有一个责任，仍然可以从一个单一的功能到一组松散相关的功能，这是一个共同的主题的一部分。只要你避免陪审团追究某件事情的责任，它不是主要设计的，或者是做一些稀释对象简单性的其他特别事情，那么违反任何你想要的原则。 p>

但是，我发现更容易获得SRP的正确性，然后再做更精细的一些更强大的功能。

An answer to a Stack Overflow question stated that a particular framework violated a plain and simple OOP rule: Single Responsibility Principle (SRP).

Is the Single Responsibility Principle really a rule of OOP?

My understanding of the definition of Object Orientated Programming is "a paradigm where objects and their behaviour are used to create software". This includes the following techniques: Encapsulation, Polymorphism & Inheritance.

Now don't get me wrong - I believe SRP to be the key to most good OO designs, but I feel there are cases where this principle can and should be broken (just like database normalization rules). I aggressively push the benefits of SRP, and the great majority of my code follows this principle.

But, is it a rule, and thus implies that it shouldn't be broken?

解决方案

Very few rules, if any, in software development are without exception. Some people think there are no place for goto but they're wrong.

As far as OOP goes, there isn't a single definition of object-orientedness so depending on who you ask you'll get a different set of hard and soft principles, patterns, and practices.

The classic idea of OOP is that messages are sent to otherwise opaque objects and the objects interpret the message with knowledge of their own innards and then perform a function of some sort.

SRP is a software engineering principle that can apply to the role of a class, or a function, or a module. It contributes to the cohesion of something so that it behaves well put together without unrelated bits hanging off of it or having multiple roles that intertwine and complicate things.

Even with just one responsibilty, that can still range from a single function to a group of loosely related functions that are part of a common theme. As long as you're avoiding jury-rigging an element to take the responsibilty of something it wasn't primarily designed for or doing some other ad-hoc thing that dilute the simplicity of an object, then violate whatever principle you want.

But I find that it's easier to get SRP correct then to do something more elaborate that is just as robust.

这篇关于单一责任原则是OOP的规则吗？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！