编写程序前的设计与思考
1.分析业务,从业务流和业务规则中归纳出领域对象.这些对象一般放在src/com/yourname/domain下.
2.根据业务,考虑为领域对象提供完整的服务需要那些服务类.这些对象一般放在src/com/yourname/service下.
3.思考从输入开始,到输出结束,程序要运行正常,服务类需要那些属性和方法,这些成员代表什么意义具有什么价值,方法的参数的返回值分别是什么.
4.思考要让服务类为领域对象类提供完整普适的服务,领域对象类需要做怎样的调整,需要归纳那些共同的基类.这里可以绘出领域类和服务类的静态类图协助思考.
5.考虑还需要那些实用类来帮助实现程序.这些对象一般放在src/com/yourname/util下.
6.在领域类和服务类的基础上设计持久层,控制层和表现层(当前阶段暂时不会接触).
软件设计的通用原则
Domain first:先归纳程序的领域对象,归纳出来才清楚程序要做什么.
Service second:其次归纳程序的服务对象,归纳出来才知道该怎么去做.
前两步完成后可以说设计已经完成了大半.
Persistence the third:再次再考虑数据如何持久化到持久层中,比如说数据库表结构的设计.
Presentation the last:最后考虑表现层的东西,比如说界面方案.
现代软件设计的核心-类的设计
从上两步可以看出,软件设计其实就是类的设计工作,类设计的结果直接影响着软件的方方面面,所谓持久层设计,表现层设计都是类设计的泛化和深化,所以说类设计直接影响着软件的兴衰成败.
那么关于类设计的准则和评价标准是什么呢?
类设计的五条基本准则
单一职责原则(The single responsibility principle): 一个类有且只有一个中心目的,它为一个中心目的所设计,只能因为中心目的相关原因而改变.
开放-封闭原则(The open-close principle):类高度内聚,和其它类的耦合程度小,应该可以在不改变类的情况下,改变类所在的环境.
里斯科夫替换原则(The Liskov substitution principle):派生类的行为为基类所规定和限制,避免使派生类的方法非法化或者退化它们.基类的使用者不需要了解派生类就能正确的通过接口使用它们.
依赖关系倒置原则(The dependecy inversion principle):基于抽象类和接口而不是具体的类形成设计构架,因为抽象类和接口相对具体类而言更不容易被改动.
接口隔离原则(The interface segregation principle):给对象的每个使用者一个单独的接口.其中只包含它们需要的方法,不要设计一个包含很多方法的接口让不需要这些接口的类去实现它们.
类的评价标准-抽象相关
类是否有一个中心目的.
类的命名是否恰当,其名字是否表现了其中心目的.
类的接口是否展现了一致的抽象.
类的接口是否让人明白的知道该如何使用它.
类的接口是否足够抽象,是你能不必顾虑它是如何进行服务的.
类提供的服务是否足够完整,能让其它类无须了解动用其内部结构.
是否已经去除无关信息.
是否考虑过把类进一步分解成组件类?是否已经尽可能将其分解.
再修改类时是否维持了其接口的完整性.
类的评价标准--封装相关
是否把类成员的可访问性降至最小.
是否避免暴露类中的数据成员.
类是否已经尽可能的对其它类隐藏了实现细节.
类是否避免对其使用者,包括其派生类如何使用它做了假设.
类是否不依赖其它类,它是松耦合的吗?
典型的设计的臭味
僵化性(Rigidiry):类之间耦合严重,系统几乎很难改变,改变一处就不得不改动其它地方,甚至引起无休止的连锁反应.
易碎性(Fragility):改变系统的某个部分,会破坏许多完全无关的部分.这一般由不必要的语法结构引起,如过度复杂的循环和分支.
固化性(Immobility):很难将系统分解成可供其它系统使用的组件,细化不够会引起这样的问题.
粘稠性(Viscosity):开发环境总是和输入输出和库粘在一起.永远走不出编辑->编译->测试这一无休止的循环,分层不清晰会引起这样的问题.
不必要的复杂性(Needless Complexity):很多充满着智慧的代码结构目前还不需要,但有一天可能会排上用场,喜欢事先考虑幽灵需求的程序员经常给代码带来这样的异味.
不必要的重复(Needless Repetition): 系统充斥着重复代码,看上去象只会VC大法(Ctrl+C,Ctrl+V)的程序员写的,懒惰不思考是造成这个问题的根源.
不透明性(Opacity):代码不能体现创建人的意图.
何谓良好的设计
设计良好的系统应该容易理解,容易改变,容易重用.它实现起来没有任何特殊的困难,简明扼要而经济.它不会散发出代码臭味,公司乐于生产这样的系统,客户乐于使用这样的系统,维护人员乐于维护这样的系统.
设计良好的现代软件特征
最小的复杂度:整个系统可以分解为简单而易于理解的各个部分.
易于维护:程序有良好的可维护性.
松散耦合,通过应用类接口中的合理抽象,封装性以及信息隐藏等原则,设计出相互关联尽可能最少的类.
适应变化: 能在不改变系统基本构架的基础上,适应未来的变化,有良好的扩展性,程序可扩展,可重用.
有明晰的层次,每层各司其职,有良好分工.
高扇入低扇出:系统很好的利用了较低层次上的工具类,重复代码很少或没有.
有良好的规范:无论多少人参与了项目,从代码看来犹如出自一人之手.
使用标准技术.