单一职责是降低耦合度的指导思想,适用于一个微服务,一个类型,一个方法。
微服务层:
微服务一般按业务的领域来进行拆分:药房微服务就是药房的业务,护士站微服务就是护士站的业务,广义上没有什么问题,但对于一些共用业务,就犯难了,究竟放在那个微服务里?还是合并两个微服务?其实这里就单一,把共用的抽离出来,不一定做成另一个微服务,可以统一做成类库,供两个微服务调用,如果业务有细微差别,可以通过设计模式来灵活解决异构情况。
类型:
这里的类型,一般指复杂类型:如结构体(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、多用一些经典的设计模式来让方法彼此隔离,互不干扰
想要更快更方便的了解相关知识,可以关注微信公众号