标签: single-responsibility-principle

我正在阅读有关OOP设计中的好坏实践的很多内容.很高兴知道你的设计很糟糕或很好.但是你如何从糟糕到好的设计？我已经从主businesslogic类拆分了接口(xaml)和codebehind.最后一堂课正在变得越来越大.我已经尝试将它分成更小的类,但我现在卡住了.关于如何拆分大班的任何想法？主类有1个不同类型的数据列表.我正在计算总数,但也计算个别类型.我有方法来执行这些计算,这些计算是从代码隐藏中处理的事件中调用的.任何想法从哪里开始？

附加信息:

我们已经进入这个项目大约6个月了.我已经使用面向对象的语言多年(第一个c ++,java和现在的c#),但从来没有像这样的大型项目.我相信我们在开始时做了一些错误的转变,我认为我们需要纠正这些.我目前无法详细说明该项目的任何细节.我打算订一两本关于设计的书.如果我将所有课程分开,我该如何将它们重新组合在一起？也许更好的是继续这种方式到第一个版本并在那之后重建部分,第二个版本？

我试图理解实际上是什么责任所以我想用一个我正在研究的东西的例子.我有一个应用程序,可以将产品信息从一个系统导入另一个系统.应用程序的用户可以选择各种设置,以便在一个系统中的哪些产品字段中使用另一个系统.

所以我有一个类,比如说ProductImporter,它的责任是导入产品.这个类很大,可能太大了.

这个类中的方法很复杂,例如getDescription.此方法不是简单地从其他系统获取描述,而是根据用户设置的各种设置设置产品描述.如果我要添加设置和获取描述的新方法,则此类可能会更改.

那么,这是两个责任吗？是否有一个进口产品和一个获得描述.看起来就是这样,几乎我所拥有的每一种方法都会出现在它自己的类中,这看起来有点矫枉过正.

我真的需要对这个原则有一个很好的描述,因为我很难完全理解.我不想要不必要的复杂性.

假设我们正在设计一个执行CRUD(创建,读取,更新和删除)操作的UserServiceImpl类.在我看来,创建,读取,更新和删除是改变类的四个原因.这个类是否违反了单一责任原则？如果违反,那么,我们应该有四个类,如CreateUserServiceImpl,ReadUserServiceImpl, UpdateUserServiceImpl,和DeleteUserServiceImpl.拥有很多课程不是一种矫枉过正的行为吗？

假设我为创建,读取,更新和删除操作定义了4个接口,我的服务类实现了所有这四个接口.现在我只能有一个实现类,但是通过分离它们的接口,就应用程序的其余部分而言,我已经解耦了这些概念.这是正确的方式还是你看到了一些问题？

我正在尝试在我的.NET MVC 3应用程序上实现此命令模式,专门用于保存对Thing的编辑.我还没有决定如何继续.在我得到实际问题之前,这里是简化的代码:

public class ThingController
{
    private readonly ICommandHandler<EditThingCommand> handler;

    public ThingController(ICommandHandler<EditThingCommand> handler)
    {
        this.handler = handler;
    }

    public ActionMethod EditThing(int id)
    {
        ...build EditThingViewModel and return with View...
    }

    [HttpPost]
    public ActionMethod EditThing(int id, EditThingViewModel vm)
    {
        var command = new EditThingCommand
        {
            ...not sure yet...
        };

        this.handler.Handle(command);

        ...redirect somewhere...
    }
}

我的EditThingViewModel完全与我的域断开连接,该域由POCO类组成.看起来我的EditThingCommand应该如下所示:

public class EditThingCommand
{
    Thing ModifiedThing;
}

但是,构建ModifiedThing仍然会在我的控制器中发生.这是本案中的大部分工作.在构建ModifiedThing时(以及应用于它的"旧"时间戳进行乐观并发检查),剩下的就是命令在我的数据上下文上调用Update.

显然,能够使用其他命令轻松装饰它是有价值的,但我也希望能够在我的控制器之外移动ModifiedThing的构造.(也许这个问题就是这个问题.)EditThingCommand在我的域中,没有对EditThingViewModel的引用,所以它不能去那里.在我的表示层中有另一个命令将我的viewmodel映射到我的poco实体是否有意义？

我无法将单一责任原则与封装协调一致.似乎在类之间分配责任需要暴露大量数据.举个例子,考虑一些叫做的对象DataPoints.DataPoints其中包括x和y坐标.我可以创建一个填充的Generator类DataPoints.现在,假设我想绘制这些数据点.显然,这是一个单独的责任,可能来自一个叫做的类DataPointsPlotter.但是为了绘制数据,我需要知道内部x和y坐标是什么.只需一个处理两个类,这没问题.x和y是内部变量,但create()和print()方法都可以访问这些变量.我可以暴露x和y(也许是通过getter/setters - 呃)或者我可以通过DataPointsPlotter类的结构,但它仍然需要进入x和y.我可以在DataPoints我发送x和y 的类中声明一个Plotter实例.但这仍然是曝光.

在这个例子中,如何使用绘图仪绘制x和y而不违反封装？

使用SOLID原则特别是SRP,我们有很多类.
我的意思是,它就像你想要构建一个数据库类
那么,你有
DatabaseHandler类来处理数据库(选择,插入,更新,删除等),

DatabaseAdapter class是一个扩展的PDO类(可以在构造中设置首选的默认模式,一个新的prepare方法直接准备语句,将它与param绑定,然后执行它,

QueryBuilder类是SelectStatementBuilder类的父,InsertStatementBuilder类, DeleteStatementBuilder类,UpdateStatementBuilder类(用于构建SQLStatement),

Expression类,用于构建WHERE子句

SQLStatement Class中所需的表达式(其行为就像普通字符串,但其接口是SQLStatementInterface,因此我们可以知道它是一个SQL语句等.

而且,我知道如果我深入挖掘并重新进行重构,将会有更多的课程.

SRP原则实施是否导致了Lasagna代码？烤宽面条的代码好吗？

我有一个MVC项目,具有以下模式

View <-> Controller <-> Service <-> Repository/Entities <-> Database

例如,如果我的数据库中有2个表(Customer和Order),那么我的Repository层中有2个类(这个类映射1:1和我的数据库表,因为我使用的是EF Code First):

public class Customer
{
     [Key]
     public int CustomerID { get; set; }
     public int Name { get; set; }
     //rest of columns here
}

public class Order
{
     [Key]
     public int OrderId { get; set; }
     //rest of columns here
}

然后我有服务:

public class CustomerService : ICustomerService
{
     void AddNewCustomer(Customer obj);
     void GetCustomerOrders(Customer obj);
     //rest of methods here
}

public class OrderService : IOrderService
{
     void GetOrderById(int …

在将身份验证初始化为AWS Cognito时,API拒绝了我的请求:

InvalidParameterException: Missing required parameter UserName
status code: 400,

这是请求的内容(是的,我尝试将它放在任何地方,没有成功).

params := &cognitoidentityprovider.InitiateAuthInput{
    AuthFlow: aws.String("USER_SRP_AUTH"),              // Required
    ClientId: aws.String("xxxxxxxxxxxxxxxx"), // Required
    AuthParameters: map[string]*string{
        "username":     aws.String("myUser"), // Required
        "UserName":     aws.String("myUser"), // Required
    },
    ClientMetadata: map[string]*string{
        "username":     aws.String("myUser"), // Required
        "UserName":     aws.String("myUser"), // Required
    },
}

请问有什么问题吗？考虑到doc(https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-dg-pdf.pdf),username应该与AuthParameters一起使用srpA.该问题是否可能来自srpA？如果是这样,这是什么？它看起来像是密码.

该单一职责原则指出：

一个班级应该有一个，而且只有一个，改变的理由。

在打开/关闭原则指出：

您应该能够扩展类行为，而无需修改它。

如果一个类应该只有一个改变的理由，但不应该被修改，那么开发人员怎么能同时尊重这两个原则呢？

例子

工厂模式是一个很好的例子，它具有单一职责，但可能违反开放/封闭原则：

public abstract class Product
{
}

public class FooProduct : Product
{
}

public class BarProduct : Product
{
}

public class ProductFactory
{
    public Product GetProduct(string type)
    {
        switch(type)
        {
            case "foo":
                return new FooProduct();
            case "bar":
                return new BarProduct();
            default:
                throw new ArgumentException(...);
        }
    }
}

当我需要ZenProduct在后期添加到工厂时会发生什么？

• 这肯定违反了开放/封闭原则吗？
• 我们如何防止这种违规行为？

今天我工作的另一位工程师问我“这是什么责任？” 我的回答如下：

“您的代码的每个范围，无论是if语句，函数，类还是模块，都应该有一个更改的理由”。

但是，在我读到的所有这篇文章中，人们都是在课堂上谈论的。我告诉他SRP适用于他的代码中的每个范围，我错了吗？