这是单一责任原则的一个例子吗？

Question

我制作了以下代码示例来学习如何使用泛型方法签名。

为了获得客户和员工的 Display() 方法，我实际上开始用 Person 抽象类替换我的 IPerson 接口。

但后来我停了下来，记得鲍勃叔叔在一个播客中告诉斯科特汉塞尔曼关于单一职责原则，其中你应该有很多小类，每个类都做一件特定的事情，即客户类不应该有一个 Print() 和 Save() 以及 CalculateSalary() 方法，但您应该有一个 CustomerPrinter 类< /em> 和 CustomerSaver 类 和 CustomerSalaryCalculator 类。

这似乎是一种奇怪的编程方式。 然而，摆脱我的界面也感觉不对（因为很多 IoC 容器和 DI 示例本身就使用它们），所以我决定尝试一下单一职责原则。

因此，以下代码与我过去编写的代码不同（我会使用 Display() 方法创建一个抽象类并摆脱接口），但基于我所听说的解耦以及 SOLID 原则，这种新的编码方式（界面和 PersonDisplayer 类）我认为这是正确的方式。

我想听听其他人是否在这个问题上有同样的想法，或者是否经历过这个问题的积极或消极影响（例如，每个班级都做一件特定的事情，数量庞大，等等）。

using System;

namespace TestGeneric33
{
    class Program
    {
        static void Main(string[] args)
        {
            Container container = new Container();
            Customer customer1 = container.InstantiateType<Customer>("Jim", "Smith");
            Employee employee1 = container.InstantiateType<Employee>("Joe", "Thompson");
            Console.WriteLine(PersonDisplayer.SimpleDisplay(customer1));
            Console.WriteLine(PersonDisplayer.SimpleDisplay(employee1));
            Console.ReadLine();
        }
    }

    public class Container
    {
        public T InstantiateType<T>(string firstName, string lastName) where T : IPerson, new()
        {
            T obj = new T();
            obj.FirstName = firstName;
            obj.LastName = lastName;
            return obj;
        }
    }

    public interface IPerson
    {
        string FirstName { get; set; }
        string LastName { get; set; }
    }

    public class PersonDisplayer
    {
        private IPerson _person;

        public PersonDisplayer(IPerson person)
        {
            _person = person;
        }

        public string SimpleDisplay()
        {
            return String.Format("{1}, {0}", _person.FirstName, _person.LastName);
        }

        public static string SimpleDisplay(IPerson person)
        {
            PersonDisplayer personDisplayer = new PersonDisplayer(person);
            return personDisplayer.SimpleDisplay();
        }
    }

    public class Customer : IPerson
    {
        public string FirstName { get; set; }
        public string LastName { get; set; }
        public string Company { get; set; }
    }

    public class Employee : IPerson
    {
        public string FirstName { get; set; }
        public string LastName { get; set; }
        public int EmployeeNumber { get; set; }
    }
}

Answer 1

我喜欢将单一职责原则视为职责分离。 在我像你们一样开始划分班级之前，我会尝试考虑每个班级应该负责什么。

正如您所提到的，您的类非常简单，并且非常适合具有已实现的 Print() 和 Save() 函数的抽象类。 我倾向于保留该设计而不是您当前的设计。

但是，如果打印和保存是更复杂的任务，可能以不同的方式执行，那么就需要专用的 Printer 或 Saver 类，因为现在的职责更加复杂。 创建新类的“复杂性”阈值是非常主观的，并且取决于具体情况，但最终，代码只是我们低等人类理解的抽象，因此使其最直观。

您的 Container 类有点误导。 它实际上并不“包含”任何东西。 它实际上实现了工厂方法模式，并且会受益于被命名为工厂。

另外，您的 PersonDisplayer 永远不会实例化，并且可以通过静态方法提供其所有功能，那么为什么不将其设为静态类呢？ 实用程序类（例如打印机或保存器）是静态的并不罕见。 除非您需要拥有具有不同属性的单独打印机实例，否则请将其保持静态。

Answer 2

我认为你走在正确的道路上。 但我并不完全确定 Container 类。 我通常会坚持使用更简单的解决方案，即仅对这些对象使用“new”，除非您对该接口有一些业务驱动的需求。 （我不认为“整洁”是这个意义上的业务需求）

但是将“成为”客户责任与“展示客户”分开是很好的。 坚持下去，这是对 SOLID 原则的很好解释。

就我个人而言，我现在已经完全停止在此类代码中使用任何类型的静态方法，并且我依靠 DI 在正确的位置获取所有正确的服务对象。 时间。 一旦您开始进一步阐述 SOLID 原则，您就会发现您正在制作更多的课程。 尝试遵循这些命名约定以保持一致。

Answer 3

好吧，我以前从未听说过这种“单一责任原则”，但在我看来，您通过拥有这些 CustomerPrinter 类和 CustomerSaver 类所做的只是将类转换回结构，并且去面向对象一切。

例如，这意味着不同的客户类型如果需要以不同的方式打印，则在 CustomerPrinter 类中需要不同的大小写。 但据我了解，OO 组织以及使用继承树等的要点之一是消除 CustomerPrinter 知道如何打印所有内容的需要：客户知道如何打印自己。

无论如何，我不认为应该严格遵循这些范式。 例如，我不确定您的情况下接口和抽象类之间有什么区别。 但话又说回来，我是一个 C++ 程序员，而不是 C# 程序员......

Answer 4

几点说明：

• 一般来说，SRP 都很好，显示格式与数据的分离也是如此。
• 考虑显示等。我宁愿从服务角度考虑，即 PersonDisplayer 是单一的、无状态的，并提供字符串 Display(IPerson) 函数。 恕我直言，一个特殊的类包装器只是提供显示并没有提供任何优势。
• 但是，如果您使用 wpf 的数据绑定，则可能有一个 DisplayablePerson 类，如果 Person 发生更改，该类将传播 PropertyChanged。 您可以将 DisplayablePerson 对象放入 ObservableCollection 并将其用作某些列表控件的 ItemsSource。

• 你需要 Container 做什么，只是为了实例化和配置实例吗？那么试试 Customer customer1 = new Customer{FirstName= "Jim", LastName= "Smith"};

• 顺便说一下，我尝试过 object.Method < SomeType>(...) 调用几次，因为它似乎是最快和最简单的解决方案。 然而，一段时间后，我总是遇到这个问题并最终得到 object.Method(Type someTypeType, ...)

Answer 5

您可能会查看 IFormattable 和 IFormatProvider。

该框架有格式化类来提供支持。