实行单一责任原则 [英] Implementation of Single Responsibility Principle

问题描述

如果我将对象分解为单一职责"，是否有一个基本的想法，例如类似的对象应该一起生活还是单独生活，例如，如果我有

If I break my Objects down to 'Single Responsibilities', is there a fundamental thought whether like objects should live together or separately, for example if I have

class Employee_DataProvider() : IEmployee_DataProvider { ... };
class Employee_Details() : IEmployee_Details { ... };
class Employee_Payroll() : IPayroll() { ... };
class Employee_LeaveProcessing() : ILeaveProcessing_Client { ... };
...

让所有这些东西都生活在里面，却又通过拥有所有者的Employee类的接口松散地耦合在一起是难闻的事吗?

Is it bad smell to have all these living inside, yet loosely coupled to through interfaces, an owning Employee class:

class Employee
{
    IEmployee_DataProvider _dataProvider;
    IEmployee_Details _details;
    IPayroll _payroll;
    ILeaveProcessing_Client _leaveProcessing;

    //My functions call the interfaces above

}

还是更多地考虑将代码中的这些类完全分开(或至少尽可能分开)?还是这两种方法都是SRP的有效用法?

or is the thinking more around keeping these classes completely separate (or as least as separate as is posible) in the code? Or are both these methods a valid usage of SRP?

编辑:我不想批评示例中给出的对象的可行性，我只是为了说明这个问题而作了铺垫.我同意数据，请假和薪资处理不是员工类别的领域.

I do not want critique on the feasibility of the object given in the example, I just made it up to illustrate the question. I agree data, leave and payroll processing are not the domain of the employee class.

尽管SRP要求我从作为真实世界表示形式的对象转移到围绕单个功能概念的作为属性和方法的对象，但确实如此

It does appear though that SRP is asking me to move away from the object as real world representation to object as a properties and methods around a single functional concept

推荐答案

尽管还没有人解决我关于原则本身的实际问题，而不是我给出的一个糟糕的例子，即一个Employee对象对流程了解得太多了影响这一点的人，对于显然对这个问题感兴趣的人(有2个最喜欢的"星星)，尽管我希望进行更多的讨论，但我还是做了一些进一步的阅读.

Although no one has yet addressed my actual question regarding the principle itself, rather than the somewhat poor example I gave, of an Employee object knowing too much about the processes that affect it, for those who are obviously interested in the question (there are 2 'favourites' stars) I've done a bit more further reading, although I was hoping for more of a discussion.

我认为，当前的两个答案试图说的是，分离的责任应该能够独立存在，而我的榜样就是不做的完美典范.我很高兴接受这一点.

I think what the two current answers are trying to say is that responsibilities separated should be able to be stand alone, and that my example was a perfect example of what not to do. I am more than happy to accept that.

ObjectMentor (鲍勃叔叔的网站)中有一段将Connection和DataReader对象(两个对象以前生活在调制解调器类中，然后分离出来)组合成ModemImplementation的示例，但声明为

There is a paragraph from ObjectMentor (Uncle Bob's site) that has an example that combines Connection and DataReader objects (two objects previously living in a modem class then separated out) into a ModemImplementation, but states

但是，请注意我已经重新耦合 将两个职责合并为一个 ModemImplementation类.这不是 理想，但可能有必要. 经常有原因，必须要做 以及硬件的详细信息或 操作系统，这迫使我们去做一些事情 我们宁愿不夫妻.然而， 通过分离他们的接口，我们有 分离了这些概念，直到 有关应用程序的其余部分.

However, notice that I have recoupled the two responsibilities into a single ModemImplementation class. This is not desirable, but it may be necessary. There are often reasons, having to do with the details of the hardware or OS, that force us to couple things that we’d rather not couple. However, by separating their interfaces we have decoupled the concepts as far as the rest of the application is concerned.

我们可以查看ModemImplementation 班级是鞭子或疣；然而， 请注意，所有依赖项都消失了 从中.没人需要依靠这个 班级.除了主要需要之外没有人 知道它的存在.因此，我们将 篱笆后面的丑陋位.它的 丑陋不需要泄漏和污染 该应用程序的其余部分.

We may view the ModemImplementation class is a kludge, or a wart; however, notice that all dependencies flow away from it. Nobody need depend upon this class. Nobody except main needs to know that it exists. Thus, we’ve put the ugly bit behind a fence. It’s ugliness need not leak out and pollute the rest of the application.

我认为注意所有依赖关系都从那里流失"这一行在这里很重要

I think the line 'notice that all dependencies flow away from it' is an important one here

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