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