标签: single-responsibility-principle

我正在寻找一些违反单一责任原则的代码示例.不要向我展示鲍勃叔叔的书籍或网站上的任何例子,因为这些都是在互联网上贴满的,就像这样:

interface Modem
{
    public void dial(String pno);
    public void hangup();
    public void send(char c);
    public char recv();
}

我有关于表单验证和业务验证的问题.我看到很多使用某种表单验证库的框架.您提交了一些值,库会验证表单中的值.如果不行,它将在您的屏幕上显示一些错误.如果全部计划,则将值设置为域对象.这里的值将是或者,更好的说,应该再次验证.很可能在验证库中进行相同的验证.我知道2个PHP框架具有这种构造Zend/Kohana.

当我看到编程和一些原则,如不要重复自己(DRY)和单一责任原则(SRP)时,这不是一个好方法.如你所见,它验证了两次.为什么不创建进行实际验证的域对象.

示例:提交包含用户名和电子邮件表单的表单.用户名字段和电子邮件字段的值将填充在2个不同的域对象中:用户名和电子邮件

class Username {}
class Email {}

这些对象验证其数据,如果无效则抛出异常.你同意吗？您如何看待这种方法？有没有更好的方法来实现验证？我对很多处理这些东西的框架/开发人员感到困惑.他们都错了还是我错过了一点？

编辑:我知道还应该有客户端类的验证.在我的意见中,这是一个不同的球赛.如果您对此有一些评论以及处理此类内容的方法,请提供.

一位开发人员和我正在交谈(轻描淡写地)对象的属性的Lazy-Loading.

• 他说要使用静态IoC查找调用来解析和延迟加载对象的对象.
• 我说这违反了SRP,并使用拥有的服务来解析该对象.

那么,在IoC和SRP之后你将如何处理Lazy-Loading？

你不能单元测试那个延迟加载的属性.他重申那句话说:"你已经为UserStatsService进行了单元测试 - 这是你的代码覆盖率." 有效点,但该物业仍然未经测试,但"完整"覆盖.

设置/代码模式:

• 项目使用严格的依赖注入规则(注入所有服务,存储库等的ctors).
• 项目通过Castle使用IoC(但可能是Unity之类的任何东西).

一个例子如下.

public class User
{
  public Guid UserId { get; set; }

  private UserStats _userStats;
  // lazy-loading of an object on an object
  public UserStats UserStats
  {
    get
    {
      if (_userStats == null)
      {
        // ComponentsLookup is just a wrapper around IoC 
        // Castle/Unity/etc.
        _userStats = 
          ComponentsLookup
            .Fetch<UserStatsService>()
              .GetByUserId(this.UserId);
      }
      return _userStats;
    }
  }
}

以上显示了延迟加载对象的示例.我说不要使用它,并从UI层访问任何需要该对象的UserStatsService.

编辑:下面的一个答案让我想起了延迟加载的NHibernate技巧,即虚拟化你的属性,允许NHibernate创建一个懒惰加载本身的过载.光滑,是的,但我们没有使用NHibernate.

没有人真正解决Lazy-Loading的问题.一些好文章和SO问题接近:

• 对具有许多依赖项的类使用依赖注入框架
• http://blog.vuscode.com/malovicn/archive/2009/10/16/inversion-of-control-single-responsibility-principle-and-nikola-s-laws-of-dependency-injection.aspx

我确实看到了延迟加载的好处.不要弄错我,我所做的只是懒惰加载我的复杂类型及其子类型,直到我切换到忍者的DI方式.好处在于UI层,其中用户的统计数据显示在具有100行的列表中.但是使用DI,现在你必须引用几行代码来获取用户统计数据(不违反SRP并且不违反Demeter法则),并且必须走这条长路径的查找次数100次.

是的,添加缓存并确保编写UserStatsService以用作Singleton模式,从而大大降低性能成本.

但我想知道是否有其他人有一个[顽固]开发人员,他们不会完全屈服于IoC和DI规则,并且拥有有效的性能/编码点来证明解决方案的合理性.

正如标题所述,为什么任何对象应该继承ToString()方法(例如在C#或Java中)并以某种方式关注将其转换为String？在某些情况下,这不违反单一责任原则吗？我的意思是,如果你的对象不需要转换为字符串,你最终会对你的对象有更多的响应能力.

在升级一些旧代码的同时,我发现了这两个OO原则似乎彼此冲突的情况.

考虑以下伪代码(它是我遇到的简化版本):

int numberOfNewRecords;
int numberOfOldRecords;
int numberOfUndefinedRecords;

void ColourAndCount()
{
    foreach(Row row in dataGridView1.Rows)
    {
        switch(row.Cells["Status"])
        {
            case: "Old"
                row.BackColor = Color.Red;
                numberOfOldRecords++;
                break;
            case: "New"
                row.BackColor = Color.Blue;
                numberOfNewRecords++;
                break;
            default:
                row.BackColor = Color.White;
                numberOfUndefinedRecords++;
                break;
        }
    }
}

这段代码做了两件事:它按照状态记录了记录的数量,并且还根据状态再次对每一行进行着色.它很麻烦,但由于这两个操作(到目前为止)总是同时被调用,因此它没有引起任何问题,并且使得像其他状态一样的维护要求很容易添加.

然而,单一责任原则告诉我,我应该将其分为两个单独的方法:

(编辑)次要说明:我刚刚意识到我可能在这里滥用"单一责任原则"一词,据我所知它指的是类."每种方法一种操作"设计模式的术语是什么？

int numberOfNewRecords;
int numberOfOldRecords;
int numberOfUndefinedRecords;

void Count()
{
    foreach(Row row in dataGridView1.Rows)
    {
        switch(row.Cells["Status"])
        {
            case: "Old"
                numberOfOldRecords++;
                break;
            case: "New"
                numberOfNewRecords++;
                break;
            default:
                numberOfUndefinedRecords++;
                break;
        }
    }
}

void Colour()
{
    foreach(Row row in …

我已经编写了UserService关于用户的类（在逻辑层，而不是持久层），它包含这些方法。

• 创造
• 修补
• 删除
• 得到一个
• 获取列表

具有这些方法的此类是否违反了SRP？

python
class UserService:

    repository: Repository

    def create(...):
        self.repository.save(...)

    def patch(...):
        self.repository.patch(...)

    def delete(...):
        self.repository.delete(...)

    def get_one(...):
        return self.repository.get(...)[0]

    def get_list(...):
        return self.repository.save(...)

如果这有很多职责我该如何分配课程？

在我写的应用程序中,我有一个Policy类.有4种不同类型的政策.每个策略都针对其他策略进行加权,例如PolicyA> PolicyB> PolicyC> PolicyD.

谁负责实施逻辑来确定一个政策是否比另一个更好？我最初的想法是重载>和<运算符并在Policy类型本身中实现逻辑.

这会违反SRP吗？

如果一个类依赖于多个其他类的接口,那就是违反了SRP,或者只是在两个接口都发生变化时才是违规,或者这完全是错误的思路？

我为不同的输入创建了一个单元测试,以确保输出正确.

[TestMethod]
    public void CountInversionTest()
    {
        #region Arrange
        int[] sourceArray = {4, 3, 2, 1};
        int correctInversionCount = 6;
        int[] sourceArray2 = { 1, 3, 5, 2, 4, 6};
        int correctInversionCount2 = 3;
        int[] sourceArray3 = { 5, 6, 2, 3, 1, 4, 7 };
        int correctInversionCount3 = 10;
        #endregion

        #region Act
        Sorter sorter = new Sorter();
        int inversionCount = sorter.CountInversion(sourceArray);
        int inversionCount2 = sorter.CountInversion(sourceArray2);
        int inversionCount3 = sorter.CountInversion(sourceArray3);
        #endregion

        #region Assert
        Assert.AreEqual(correctInversionCount, inversionCount);
        Assert.AreEqual(correctInversionCount2, inversionCount2);
        Assert.AreEqual(correctInversionCount3, inversionCount3);
        #endregion
    } …

我试图理解单一责任原则。我有以下问题。

1. 单一职责原则 (SRP) 规定，类的更改不应有多个原因。通常我们的Resource、Service和Repository类都有create、read、update和delete方法。我们正在更改每个类以修改任何这些操作的代码。是否违反SRP？我们需要为每个动作单独的类吗？

2. 当我运行声纳 lint 时，我看到了以下消息。

   类不应该与太多其他类耦合。

   这里我使用 spring DI 注入其他类。依赖项数量有限制吗？

我可能错过了这个概念的关键。请推荐一个很好的资源，通过示例更好地理解这个概念