标签: single-responsibility-principle

我们目前正在使用大约7项服务.那里很大.

有没有人对单一责任原则和WCF服务有任何经验？这是否意味着你最终会得到很多小合同？如果是这样,您如何在您的应用程序中管理这些？

我正在阅读鲍勃·马丁的OOD原则,特别是SRP文本,我理解它说的很好的精神,但我不太明白一个特定的措辞,从链接的第2页(本书的第150页) ):

我解释说:

将这两个职责分成不同的类非常重要,因为每个职责都是变革的轴心.

这里的"变化轴"究竟是什么意思？

我有一个发送GET请求的方法,如下所示:

private JArray GetRESTData(string uri)
{
    try
    {
        var webRequest = (HttpWebRequest)WebRequest.Create(uri);
        var webResponse = (HttpWebResponse)webRequest.GetResponse();
        var reader = new StreamReader(webResponse.GetResponseStream());
        string s = reader.ReadToEnd();
        return JsonConvert.DeserializeObject<JArray>(s);
    }
    catch // This method crashes if only one json "record" is found - try this:
    {
        try
        {
            MessageBox.Show(GetScalarVal(uri));
        }
        catch (Exception ex)
        {
            MessageBox.Show(ex.Message);
        }
    }
    return null;
}

...我通过在webRequest和webResponse的赋值之间加入来修改它来处理POST请求:

if (uri.ToUpper().Contains("POST"))
{
    webRequest.Method = "POST";
    webRequest.ContentLength = 0;
}

...并将其重命名为GetOrPostRESTData()

但这违反了单一责任原则.

然而,如果我将它变成两个方法,POST方法与GET方法相同,除了条件中另外两行代码("if Post")之外,我违反了DRY,大部分代码都是一样的.

还有第三种方式吗？中途？或者我必须在这两种违规行为中做出选择 我被困在DRY和SOLID之间.

根据单一责任原则:

每个班级都应对软件提供的单一功能负责

单例可以防止创建类的多个实例,从而提供对它的全局访问.

但是这个功能与该类的实际功能及其应该提供的内容无关.

这是否意味着Singleton模式违反了SRP？

我最近被分配到一个公共方法中设计一个包含业务逻辑的类

 class MyClass
       private BusinessObject object;
       public BigInteger calculateCost() {
              //do calcualation using properties of object
       }
 }

在方法calculateCost()中完成的计算完全没问题,但是对象的其他属性可以改变计算的方式.所以基于某些条件我应该可以应用折扣,有多个条件,每个都可以改变计算完成.

所以我通过创建如下的私有方法来应用这种简单的方法

     private calculateCost1() {
           //using object's properties calculate the cost
     }

     private calcualteCost2() {
           //using object's properties calculate the cost
     }

并从公共方法中调用这些方法

      public BigInteger calculateCost() {
              //do calcualation using properties of object
              calculateCost1();
              calculateCost2();
      }

这种设计的缺点是,如果我需要添加额外的计算方法,我将不得不更改MyClass,但我得到的反馈是它不遵循单一责任原则.我认为班级的唯一责任是计算成本,并且在添加额外的方法来根据业务对象的属性计算成本的方式不同之后,它仍然坚持SRP.

任何人都可以评论为什么这个设计不遵循SRP,如果它不是真的？

我正在努力理解单一责任原则,但我很难掌握这个概念.我正在阅读"Lucian-Paul Torje的Java设计模式和最佳实践; Adrian Ianculescu; Kamalmeet Singh."

在本书中,我正在阅读单一责任原则章节,其中有一个汽车类,如下所示:

他们说Car拥有Car逻辑和数据库操作.将来,如果我们想要更改数据库,那么我们需要更改数据库逻辑,并且可能还需要更改汽车逻辑.反之亦然......

解决方案是创建两个类,如下所示:

我的问题是,即使我们创建了两个类,让我们考虑我们在CAR类中添加一个名为'price'的新属性[或者将属性'model'更改为'carModel']然后你认为我们还不需要更新CarDAO类就像改变SQL一样.

那么SRP在这里有什么用？

当我必须保证的过程相当复杂时，我总是有一个问题，如何保证单一责任原则。

我使用 3 层架构后端：控制器（我的 API 端点）| 服务（单一职责功能）| 数据（访问数据库）

假设我有一个由 4 个任务, , ,ProcessA组成的流程。TasksA1TasksA2TasksA3TasksA4

如果我的控制器层上公开了一个端点，例如：POSTMethodProcessA

应该如何编写我的代码以尊重我的服务层的单一责任原则？

我看到的选项：

选项1（控制器必须知道该过程）：

class MyController {
  exports.processA = functions.https.onRequest(req, res) => {
    myservice.doTaskA1(); // single responsability on task1
    myservice.doTaskA2(); // single responsability on task1
    myservice.doTaskA3(); // single responsability on task1
    myservice.doTaskA4(); // single responsability on task1
  });
}

选项 2（服务了解流程并放弃单一责任）

class MyController {
  exports.processA = functions.https.onRequest(req, res) => {
    myservice.doProcessA();
  });
}

//inside the service (the doProcessA …

我实现了一个类EUMemberChecker，负责检查一个国家是否是欧盟成员。为了完成其工作，该类包含一个方法public bool IsEUMember(string country)。用于检查一个国家是否是欧盟成员的数据存储在 PostgreSQL 数据库表中。

我想通过 DI 将此类添加为单例服务，从而使其可用AddSingleton。原因是它应该只在应用程序启动时从数据库加载一次欧盟成员。如果我通过添加此类AddScoped，则它的每个实例都需要从数据库加载自己的欧盟成员列表，在我看来，这将是相当大的开销。

我的问题是我无法将此类添加为单例，因为它使用我的DbContext类作为范围服务添加。无论如何这样做，都会导致运行时错误Dependency ...DatabaseContext {ReturnDefault} as parameter "context" reuse CurrentScopeReuse {Lifespan=100} lifespan shorter than its parent's: singleton ... {ReturnDefault} as parameter ...。

因此，似乎我必须将我的类添加为范围服务，从而导致额外的数据库调用来为该类的每个实例加载欧盟成员国。

我在这里是否错误地应用了单一职责原则，或者如何解决这个问题？如何确保欧盟成员不会无故多次从数据库加载？

我有一个基本抽象类,它聚合了一个集合中的一堆项目:

abstract class AMyAbstract
{
    List<string> Items { get; private set; }

    public AMyAbstract(IEnumerable<string> items)
    {
        this.Items = new List<string>(items);
    }
}

有很多子类,让我们为它们命名Foo,Bar,Baz,等他们都是一成不变的.现在我需要一个merge()方法,它将合并items两个对象,如下所示:

abstract class AMyAbstract
{
    // ...
    public AMyAbstract merge(AMyAbstract other)
    {
        // how to implement???
    }
}

Foo foo1 = new Foo(new string[] {"a", "b"});
Bar bar1 = new Bar(new string[] {"c", "d"});
Foo fooAndBar = foo1.merge(bar1);
// items in fooAndBar now contain: {"a", "b", …

我想更多地了解单一责任。如果我尝试代表可以添加，删除，更新，检索的客户，那么过去我的客户类将具有所有的add，remove，update和get方法。这有助于将现实世界中客户的行为归为一类。我只负责将客户类别分为AddCustomer类，删除客户类别，更新客户类别和获取客户类别，甚至获取所有客户类别？