台州网站制作服务,做直播网站一定要idc吗,徐州网站制作功能,找个可以直接看的网站单一职责是降低耦合度的指导思想#xff0c;适用于一个微服务#xff0c;一个类型#xff0c;一个方法。微服务层#xff1a;微服务一般按业务的领域来进行拆分#xff1a;药房微服务就是药房的业务#xff0c;护士站微服务就是护士站的业务#xff0c;广义上没有什么问… 单一职责是降低耦合度的指导思想适用于一个微服务一个类型一个方法。微服务层微服务一般按业务的领域来进行拆分药房微服务就是药房的业务护士站微服务就是护士站的业务广义上没有什么问题但对于一些共用业务就犯难了究竟放在那个微服务里还是合并两个微服务其实这里就单一把共用的抽离出来不一定做成另一个微服务可以统一做成类库供两个微服务调用如果业务有细微差别可以通过设计模式来灵活解决异构情况。类型这里的类型一般指复杂类型如结构体(struct)接口(interface)抽类(abstract class)实例化类(class)记录(record)。这此类型内部重要的成员有属性方法正是这些成员的规划是决定这些类型是否职责单一的重要指标。比如下面的用户类型这样的定义是不没有错误的对于一些小型项目这样定义是最经济的。 /// summary/// 用户/// /summaryclass User{/// summary/// 用户名 /// /summarypublic string UserName { get; set; }/// summary/// 密码/// /summarypublic string Password { get; set; }/// summary/// 性名/// /summarypublic string Name { get; set; }/// summary/// 性别 true男false为女/// /summarypublic bool Sex { get; set; }/// summary/// 职务/// /summarypublic string Position { get; set; }/// summary/// 生日/// /summarypublic DateTime Birthday { get; set; }}
如果从单一职责考虑这个类可以分为三个类如下 /// summary/// 用户/// /summaryclass User{/// summary/// 用户名 /// /summarypublic string UserName { get; set; }/// summary/// 密码/// /summarypublic string Password { get; set; }}/// summary/// 人员职务/// /summaryclass Position{/// summary/// 职务名称/// /summarypublic string PositionName { get; set; }}/// summary/// 人员/// /summaryclass Person{/// summary/// 人员编号/// /summarypublic string PersonNo { get; set; }/// summary/// 性名/// /summarypublic string Name { get; set; }/// summary/// 性别 true男false为女/// /summarypublic bool Sex { get; set; }/// summary/// 年龄/// /summarypublic int Age { get; set; }/// summary/// 用户/// /summarypublic User User { get; set; }/// summary/// 职务/// /summarypublic Position[] Positions { get; set; }}
分开以后虽然代码增多了但每个类的作用就单一了用户就是用户人员就是人员职务分出来当其扩展时其他类型也不受影响。方法越往下层单一职责的把握越困难特别是在写一个方法的时候单一的这个单位很模糊怎么就算单一比如写一个发送数据模块主要分部分组织数据发送数据也就对应两个方法BuildData,SendData可能在组织数据时发现有些数据得作转换比如时间类型等这时可以在BuildData里作转换当然也可以把转换这部分抽离出来组成一个TransformData纠结的是有时转换数据只要一行代码如果按单一职责思想应该分离出来但看到分离的代码觉得差强人意有没有一个标准呢这里我给出我自己的标准仅代表自己的认识1、在纠结一个方法要不要拆开时第一考虑是业务的单一性2、有些业务之间当前状态统一的要联想下一步状态或下一阶段这种状态是否持续(不要关心这个状态在现实中什么时间到来)3、多用一些经典的设计模式来让方法彼此隔离互不干扰
