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

我做了以下代码示例,以了解如何使用泛型方法签名.

为了得到一个显示()方法为客户与员工,其实我开始取代我的IPerson接口与一个人抽象类.

但后来我停下来,记得一个播客,其中鲍勃叔叔告诉Scott Hanselman关于单一责任原则,你应该有很多小班,每个人做一件特定的事情,即一个Customer类不应该有一个Print()并保存()和CalculateSalary()方法,但您应该有CustomerPrinter类 和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("Jim", "Smith");
            Employee employee1 = container.InstantiateType("Joe", "Thompson");
            Console.WriteLine(PersonDisplayer.SimpleDisplay(customer1));
            Console.WriteLine(PersonDisplayer.SimpleDisplay(employee1));
            Console.ReadLine();
        }
    }

    public class Container
    {
        public T InstantiateType(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; }
    }
}

Ben S.. 8

我喜欢将单一责任原则视为职责分离的实施.在我开始分割我的课程之前,我会尝试考虑每个课程应该负责的内容.

你的类非常简单,非常适合于一个带有你所提到的实现Print()和Save()函数的抽象类.我倾向于将这种设计保留在你当前的设计之上.

但是,如果打印和保存是更复杂的任务,可能以不同的方式执行,那么专属Printer或Saver类是必要的,因为现在责任更加复杂.制作新课程的"复杂性"阈值非常主观,并且取决于具体情况,但最终,代码只是我们低级人类理解的抽象,因此使其成为最直观的.

你Container上课有点误导.它实际上并不包含任何东西.它实际上实现了工厂方法模式,并且可以从命名工厂中受益.

此外,您PersonDisplayer永远不会实例化,并且可以通过静态方法提供其所有功能,那么为什么不将其设置为静态类呢？像Printers或savers这样的实用程序类是静态的并不罕见.除非您需要具有不同属性的打印机的单独实例,否则请将其保持静态.

我喜欢将单一责任原则视为职责分离的实施.在我开始分割我的课程之前,我会尝试考虑每个课程应该负责的内容.

你的类非常简单,非常适合于一个带有你所提到的实现Print()和Save()函数的抽象类.我倾向于将这种设计保留在你当前的设计之上.

但是,如果打印和保存是更复杂的任务,可能以不同的方式执行,那么专属Printer或Saver类是必要的,因为现在责任更加复杂.制作新课程的"复杂性"阈值非常主观,并且取决于具体情况,但最终,代码只是我们低级人类理解的抽象,因此使其成为最直观的.

你Container上课有点误导.它实际上并不包含任何东西.它实际上实现了工厂方法模式,并且可以从命名工厂中受益.

此外,您PersonDisplayer永远不会实例化,并且可以通过静态方法提供其所有功能,那么为什么不将其设置为静态类呢？像Printers或savers这样的实用程序类是静态的并不罕见.除非您需要具有不同属性的打印机的单独实例,否则请将其保持静态.