单一职责是降低耦合度的指导思想，适用于一个微服务，一个类型，一个方法。

微服务层：

　　微服务一般按业务的领域来进行拆分：药房微服务就是药房的业务，护士站微服务就是护士站的业务，广义上没有什么问题，但对于一些共用业务，就犯难了，究竟放在那个微服务里？还是合并两个微服务？其实这里就单一，把共用的抽离出来，不一定做成另一个微服务，可以统一做成类库，供两个微服务调用，如果业务有细微差别，可以通过设计模式来灵活解决异构情况。

类型：

　　这里的类型，一般指复杂类型：如结构体(struct)，接口(interface)，抽类(abstract class)，实例化类(class)，记录(record)。这此类型内部，重要的成员有属性，方法，正是这些成员的规划，是决定这些类型是否职责单一的重要指标。

　　比如下面的用户类型，这样的定义是不没有错误的，对于一些小型项目，这样定义是最经济的。

 /// <summary>
    /// 用户
    /// </summary>
    class User
    {
        /// <summary>
        /// 用户名 
        /// </summary>
        public string UserName { get; set; }
        /// <summary>
        /// 密码
        /// </summary>
        public string Password { get; set; }
        /// <summary>
        /// 性名
        /// </summary>
        public string Name { get; set; }
        /// <summary>
        /// 性别 true男，false为女
        /// </summary>
        public bool Sex { get; set; }
        /// <summary>
        /// 职务
        /// </summary>
        public string Position { get; set; }
        /// <summary>
        /// 生日
        /// </summary>
        public DateTime Birthday { get; set; }
    }

　　如果从单一职责考虑，这个类可以分为三个类，如下：

/// <summary>
    /// 用户
    /// </summary>
    class User
    {
        /// <summary>
        /// 用户名 
        /// </summary>
        public string UserName { get; set; }
        /// <summary>
        /// 密码
        /// </summary>
        public string Password { get; set; }
    }

    /// <summary>
    /// 人员职务
    /// </summary>
    class Position
    {
        /// <summary>
        /// 职务名称
        /// </summary>
        public string PositionName { get; set; }
    }

    /// <summary>
    /// 人员
    /// </summary>
    class Person
    {
        /// <summary>
        /// 人员编号
        /// </summary>
        public string PersonNo { get; set; }
        /// <summary>
        /// 性名
        /// </summary>
        public string Name { get; set; }
        /// <summary>
        /// 性别 true男，false为女
        /// </summary>
        public bool Sex { get; set; }

        /// <summary>
        /// 年龄
        /// </summary>
        public int Age { get; set; }

        /// <summary>
        /// 用户
        /// </summary>
        public User User { get; set; }

        /// <summary>
        /// 职务
        /// </summary>
        public Position[] Positions { get; set; }
    }

　　分开以后，虽然代码增多了，但每个类的作用就单一了，用户就是用户，人员就是人员，职务分出来当其扩展时其他类型也不受影响。

方法：

　　越往下层，单一职责的把握越困难，特别是在写一个方法的时候，单一的这个单位很模糊，怎么就算单一？
　　比如写一个发送数据模块，主要分部分：组织数据，发送数据，也就对应两个方法BuildData,SendData，可能在组织数据时发现，有些数据得作转换，比如时间，类型等，这时可以在BuildData里作转换，当然也可以把转换这部分抽离出来，组成一个TransformData，纠结的是，有时转换数据只要一行代码，如果按单一职责思想应该分离出来，但看到分离的代码觉得差强人意，有没有一个标准呢？

　　这里我给出我自己的标准（仅代表自己的认识）：

　　1、在纠结一个方法要不要拆开时，第一考虑是业务的单一性
　　2、有些业务之间当前状态统一的，要联想下一步状态，或下一阶段，这种状态是否持续(不要关心这个状态在现实中什么时间到来)

　　3、多用一些经典的设计模式来让方法彼此隔离，互不干扰

 

　　想要更快更方便的了解相关知识，可以关注微信公众号