面向设计原则理解

    面向对象设计(OOD)核心原则让我的程序模块达到“高内聚低耦合”,这是来自于30年前兴起的结构化设计(structured Design),但是同样适用于我们的OOD。

1.高内聚:

    高内聚是指某个特定模块(程序,类型)都应完成一系列相关功能,描述了不同程序,类型中方法,方法中不同操作描述的逻辑之间的距离相近。高内聚意味可维护性,可重新性,因为模块对外部的依赖少(功能的完备性)。如果两个模块之间的修改,互不影响这说明模块之间是高内聚的。模块的内聚和其担当的职责成反比,即,模块的职责越多,模块的内聚性越低,这也是模块的单一原则(SRP),SRP提倡每个类型都最好只承担单一的职责,只有单一的改变因素。

2.低耦合:

   耦合是描述模块之间的依赖程度,如果一个模块的修改,都有影响另一个模块则,两模块之间是相互依赖耦合的。(依赖具有传递性,耦合的两个模块可能间接依赖),低耦合是我们的设计目的,但不是不存在耦合不存在依赖,依赖是必须的,因为模块之间必须通信交互,不过好的设计依赖应该依赖于不变或者不易变的接口,无需了解模块的具体实现(OO封装性)。

  在面向对象:我们可以简述为功能完备(高内聚)的对象之间的交互是依赖于不变或不易变的接口契约(低耦合)。

  实现高内聚低耦合:行之有效的方式是分了关注点(SOC),将系统拆分成功能不同没有重叠功能集。每个功能只关注一个方面(Aspect)保证模块之间功能没有或者尽量少的重复。模块化内部实现细节隐藏,只暴露必须的接口,使得模块之间依赖于抽象,达到稳定。分离关注点的思想存在于我们软件设计的各个领域。如在.net的世界里SOA(面向服务架构)、微服务:服务就是关注点,只暴露出必要的契约。分层架构从逻辑上利用接口抽象信息隐藏,减少依赖。MVC、MVP、PM(MVVM)也是遵循分了关注点原则,达到表现层和逻辑的分离。

面向对象设计原则:

1.降低耦合度:对象直接需要交互,这就存在依赖,为了实现低耦合就必须减少依赖,依赖于稳定或不易变抽象。考虑如下订单日志记录场景:我们需要在订单每部操作记录更改日志。

public class OrderManager

{

   public void Create(Order order)

  {

      //订单处理.

     Logger log = new Logger();

     var history=GetHistory();

     log.log(history);

 }

}

  在这里我们的OrderManager和Logger存在高耦合,Logger类的修改可能导致OrderManager的修改,而且不能随意切换我们的日志记录方式,比如文件,控制台,数据库等日志方式。

 

  面向抽象编程提出抽象(接口,abstract类)是不易变的稳定抽象;对于OrderManager来说我不需要了解日志记录组件内部,只需要明白提供那些接口可用,怎么用。

public interface ILogger

{

  void Log(History history);

}

public class Logger

{

  public void Log(History history)

{

//内部实现
 
};

}

那么我们可以从设计模式工厂模式(工厂模式是负责一些列相似对象的创建)Create 日志组件ILogger。 

我们的OrderManager 就可以实现为:

ILogger log =LoggerFactory.Create();

log.Log(history);

这样我们的OrderManager就依赖于ILogger,而隔离Logger具体实现,将依赖于抽象,把变化缩小到Factory内部(同样也可以用抽象工厂),如果日志实现变化我们可以重新实现ILogger ,修改Factory逻辑,如果内部利用配置我的需求变更转移到配置。这就是面向对象第一原则,依赖于抽象而隐藏实现。(利用IOC是一种更好的方式) 

2.代码的重用性:尽量保证相同功能代码只出现一次(Code once run anywhere)。代码的重用在面对对象设计中有继承和组合两种方式,一般推荐组合优先。组合依赖于接口,组合更安全,易于维护,测试。继承存在父类访问权限,父类的修改导致子类的变化,太多的继承也有导致派生类的膨胀,维护管理也是件头痛的事。

3.开闭原则(OCP):表述拥抱需求变化,尽量做到对模块的扩展开发,修改关闭。对于新增需求我们完美的做法是新增类型而不是修改逻辑,这就意味着我们必须使用组合或者是继承体系(为了避免上一条重用性,我的继承应该是干净的继承体系,派生类应该只是新增功能而不是修改来自父类上下文),

4.里氏替换(LSP):表述派生类应该可以在任何地方替代父类使用。并不是所有的子类都可以完全替换子类,比如设计父类私有上下文信息的访问,导致子类无法访问。

5.依赖倒置(DIP):描述组件之间高层组件不应该依赖于底层组件。依赖倒置是指实现和接口倒置,采用自顶向下的方式关注所需的底层组件接口,而不是其实现。DI框架实现IOC(控制反转)就是DIP很好的插入底层组件构造框架(分构造注入,函数注入,属性注入)。微软Unity,Castle windsor,Ninject等框架支持。

最后分离关注点,衍生出声明式编程,面向方面编程(AOP)实现纵切关注点,把具体业务逻辑和日志安全等框架集公用逻辑分离。 关于IOC/AOP参见博客我的IOC/AOP随笔目录 不在累赘。

 

作者:破  狼 
出处:http://www.cnblogs.com/whitewolf/ 
本文版权归作者,欢迎转载,但未经作者同意必须保留此段声明,且在文章页面明显位置给出原文连接,否则保留追究法律责任的权利。该文章也同时发布在我的独立博客中-个人独立博客博客园--破狼51CTO--破狼。https://yq.aliyun.com/articles/new?spm=5176.100239.yqblognav1.2.soBjhr

时间: 2024-11-03 02:07:06

面向设计原则理解的相关文章

软件架构设计箴言理解

     今天和师弟聊天聊到他们项目开发,有些同事总是提前考虑性能优化,需求变更又是一大堆的重写,让我想起了Donald Knuth 提到的:对软件的过早地优化是万恶的根源.这里就简单的说几条重要的软件名人哲学. 1:软件中唯一不变的就是变化.      在软件开发过程中需求是不停的变化,随着客户对系统的认识,和现有开发功能和软件的认识,也许以开始他提出的需求就是背离的.记得网上有一句笑话,师说需求变化的:   程序员XX遭遇车祸成植物人,医生说活下来的希望只有万分之一,唤醒更为渺茫.可他的Le

微服务的4大设计原则和19个解决方案

作者|郝炎峰 编辑|小智 本文将介绍微服务架构的演进.优缺点和微服务应用的设计原则,然后着重介绍作为一个"微服务应用平台"需要提供哪些能力.解决哪些问题才能更好的支撑企业应用架构. 注:本文转载自公众号 EAWorld,已获授权. 写在前面 微服务架构现在是谈到企业应用架构时必聊的话题,微服务之所以火热也是因为相对之前的应用开发方式有很多优点,如更灵活.更能适应现在需求快速变更的大环境. 微服务平台也是我目前正在参与的,还在研发过程中的平台产品,平台是以 SpringCloud 为基础

微服务的4个设计原则和19个解决方案

微服务架构现在是谈到企业应用架构时必聊的话题,微服务之所以火热也是因为相对之前的应用开发方式有很多优点,如更灵活.更能适应现在需求快速变更的大环境. 本文将介绍微服务架构的演进.优缺点和微服务应用的设计原则,然后着重介绍作为一个"微服务应用平台"需要提供哪些能力.解决哪些问题才能更好的支撑企业应用架构. 微服务平台也是我目前正在参与的,还在研发过程中的平台产品,平台是以SpringCloud为基础,结合了普元多年来对企业应用的理解和产品的设计经验,逐步孵化的一个微服务应用平台. 一.微

超越设计模式:深入探讨超越设计模式之外的设计原则

可复用面向对象软件的基础 -- 设计模式,以其可复用的设计初衷.精巧的逻辑思维被广大面向对象程序设计所追捧.但不少程序设计者却经常将思考的问题转换为遇到了什么场景就要用什么模式.这种八股文式的思维在某种程度上严重影响了程序设计的艺术性,并固化了程序设计者的思想,违背了设计模式的初衷.在本文中,作者总结了设计模式背后的核心思想,并提出了几个关键的设计原则,例如面向接口.封装变化.依赖倒置原则.只和朋友交谈等.程序设计者只需在程序设计时遵循这些原则,便会发现原来已经在使用某些设计模式了. 引题 GO

总结的几个Python函数方法设计原则

  这篇文章主要介绍了总结的几个Python函数方法设计原则,本文讲解了每个函数只做一件事.保持简单.保持简短.输入使用参数.输出使用return语句等内容,需要的朋友可以参考下 在任何编程语言中,函数的应用主要出于以下两种情况: 1.代码块重复,这时候必须考虑用到函数,降低程序的冗余度 2.代码块复杂,这时候可以考虑用到函数,增强程序的可读性 当流程足够繁杂时,就要考虑函数,及如何将函数组合在一起.在Python中做函数设计,主要考虑到函数大小.聚合性.耦合性三个方面,这三者应该归结于规划与设

Java程序员应当知道的10个面向对象设计原则

(设计原则)底线是永远追求高内聚.低耦合的编码或设计. Apache 和 Sun的开源代码是学习Java和OOPS设计原则的良好范例.它们向我们展示了,设计原则在Java编程中是如何使用的.Java JDK 使用了一些设计原则:BorderFactory类中的工厂模式.Runtime类中的单例模式.java.io 类中的装饰器模式.顺便说一句,如果您真的对Java编码原则感兴趣,请阅读Joshua Bloch 的Effective Java,他编写过Java API.我个人最喜欢的关于面向对象设

程序员应知道这十大面向对象设计原则

面向对象设计原则是OOPS编程的核心, 但我见过的大多数Java程序员热心于像Singleton (单例) . Decorator(装饰器).Observer(观察者) 等设计模式, 而没有把足够多的注意力放在学习面向对象的分析和设计上面.学习面向对象编程像"抽象"."封装"."多态"."继承" 等基础知识是重要的,但同时为了创建简洁.模块化的设计,了解这些设计原则也同等重要.我经常看到不同经验水平的java程序员,他们有的不

交互设计原则–待续

我们认为目标导向设计方法由4个P组成,即process.pattern.principles.practices(过程.模式.原则.实践),下面我将和大家一起讨论前3个P.交互设计总的来说是一件困难杂乱的工作,交互设计师常常被要求在紧迫的工期中想象和定义一个可能要运用最新科技,并且是谁都没见过的东西,我们必须深刻地了解产品所属的复杂的领域,必须平衡好竞争的优先次序,必须理解所用科技的约束和机会,还要对整个项目的商业环境有清楚的认识.这些让人眩晕的困难和挑战迫使我们必须要采用非常系统的方法,通过需

选择合适创意的设计原则

经常有人问我怎样才能从头脑风暴中所获得的数以百计的创意中选出合适的一个.除了靠直觉和经验外,还有一种方法可以帮我们来决定和界定设计原则.在2007年以前,我们将这些原则称为"设计标准",直到我看到了Rachel Hinman所编写的"大众计算工作室:移动用户体验设计原则"这篇文章. 什么是设计原则 设计原则描述了一项产品或服务体验的核心价值.设计原则的编写应该简短易记.而作为设计师,在做项目的时候则应将这些原则熟记于心.即便有些功能交叉,但一个优秀的设计原则通常都具