SERVICE层编码规范.doc

目录1. 设计思想 . 敏捷设计概念 . 单一职责原则(SRP) . 开放-封闭原则(OCP) . 关键是抽象 . 里氏代换原则(LSP) . 依赖倒置原则(DIP) . 层次化 . 使用spring来应用该原则 . 接口隔离原则(ISP) 62. Spring框架的使用 . 容器 . 配置元数据 . BEAN的命名规范 . 实例化bean . 配置文件bean属性详解 . Bean定义的继承 . AOP编程 . 概念 . SpringAOP的支持方式 . SpringAOP使用例子 . 切入点类型支持 12设计思想SERVICE层整个WEB系统中负责业务逻辑处理的一块,是最需要抽象的部分,这一层设计的核心就是复用性,和低耦合性,结合spring提供的依赖注入方式,让业务逻辑的处理的代码调用更方便敏捷设计概念敏捷设计是一个过程,不是一个事件,它是一个持续的应用原则,模式以及实践来改进软件的结构和可读性的过程。敏捷开发人员应该做到的:(1)他们遵循敏捷实践去发现问题;(2)他们应用设计原则去诊断问题;(3)他们应用适当的设计模式去解决问题对于我们的营销系统,改进目前框架复杂,高耦合,低移植性的最佳方法就是抽象,在应用抽象的思想时,我们需要尽量的遵循以下几种设计原则:单一职责原则(SRP)就一个类而言,应该仅有一个引起它变化的原因。职责简单一些,复用更加轻松。手机虽然可以拍照,但是效果很差。如果一个类承担的职责过多,就等于把这些职责耦合在一起,一个职责的变化可能会削弱或者抑制这个类完成其它职责的能力。这种耦合会导致脆弱的设计,当变化发生时,设计会遭受到意想不到的破坏。如果你能够想到多于一个的动机去改变一个类,那么这个类就具有多于一个的职责,那就需要将类的职责分离。在SERVICE的设计时,一个接口或者类一定要仅满足一个抽象的业务需求,如果有多于一个的时候,就需要把类拆分开来开放-封闭原则(OCP)本原则是说:软件实体(类、模块、函数等等)应该可以扩展,但是不可修改。面对需求的改变却可以保持相对稳定,从而使得系统可以在第一个版本以后不断推出新的版本。无论模块是多么的“封闭”,都会存在一些无法对之封闭的变化。既然不可能完全封闭,设计人员必须对于他设计的模块应该对哪种变化封闭做出选择。他必须先猜测出最有可能发生的变化种类,然后构造抽象来隔离那些变化。在我们最初编写代码时,假设变化不会发生。当变化发生时,我们就创建抽象来隔离以后发生的同类变化。面对需求,对程序的改动是通过增加新代码进行的,而不是更改现有的代码——这就是开放封闭原则的精神所在。关键是抽象例如我们的划分功能,可能有多种划分方式,而根据不同的客户类型,可能会使用不同的划分方式,这时候我们就应该把划分方式抽象为一个接口,或者抽象类,这样我们使用时只通过接口来调用,而不关心具体实现,如果有新的划分方式我们只需要增加一个实现,而不需要再改变接口了注意:以后如果有这种业务的不同方式,都应该使用抽象来调用,比如营销单的派单方式,维系挽留的不同预警类型,都应该使用抽象来设计里氏代换原则(LSP)白话:一个软件实体如果使用的是父类的话,那么一定适用于其子类,而且它察觉不出父类对象和子类对象的区别[ASD]。也就是说,在软件里面,把父类都替换成它的子类,程序的行为没有变化。简单地说,子类型必须能够替换掉它们的父类型。只有当子类可以替换掉父类,软件单位的功能不受到影响时,父类才能真正被复用,而子类也能够在父类的基础上增加新的行为。参见下面的代码:动物*animal=new猫();animal->吃();animal->喝();animal->叫();如果需求发生变化,需要将“猫”更换成别的动物,只需要更改第一句即可,其它地方无需改变。这就是“面向接口编程”的好处。依赖倒置,其实就是谁也不要依靠谁:除了约定的接口,大家都可以灵活自如。由于有了里氏代换原则,才使得开放-封闭成为了可能。正是由于子类型的课题唤醒才使得使用父类类型的模块在无需修改的情况下就可以扩展[7]。依赖倒置,其实可以说是面向对象设计的标志,用哪种语言来编写程序不重要,如果编写时考虑的都是如何针对抽象编程而不是针对细节编程,即程序中所有的依赖关系都是终止于抽象类或者接口,那就是面向对象的设计,反之就是过程化的设计。依赖倒置原则(DIP)解释:抽象不应该依赖细节,细节应该依赖抽象。白话一点:针对接口编程,不要对实现编程。面向过程开发的问题:为了使得常用代码可以复用,通常将常用代码写成函数库。这就是“高层模块依赖低层模块”