设计的普遍规律,不只单讲如何设计类,向上到整个组件的设计,向下到类中单个方法的设计
单一职责原则——SRP
就一个类而言,应该仅有一个引起它的变化的原因
原则
最简单,最单纯的事情最容易控制,最有效
类的职责简单而且集中,避免相同的职责分散到不同的类之中,避免一个类承担过多的职责
减少类之间的耦合
当需求变化时,只修改一个地方
组件
每个组件集中做好一件事情
组件的颗粒度
发布的成本
可重用的成本
方法
避免写臃肿的方法
Extract Method
重构
Move Field/Move Class
Extract Method/Extract Class
最简单的,也是最难以掌握的原则
实例分析
Olite
开放封闭原则——OCP
软件实体(类,模块,函数)应该是可以扩展的,但是不可修改的
原则
对扩展是开放的,当需求改变时我们可以对模块进行扩展,使其具有新的功能
对更改是封闭的,对模块扩展时,不需要改动原来的代码
面对抽象而不是面对细节,抽象比细节活的更长
僵化的设计——如果程序中一处改动产生连锁反应。
方法
条件case if/else 语句
重构
Replace Type Code With Class
Replace Type Code With State/Strategy
Replace Conditional with polymorphism
实例
插件
数据驱动的OrderCycle
Liskov替换原则 LSP
子类型必须能够替换它的基类型
原则
主要针对继承的设计原则
所有派生类的行为功能必须和客户程序对其基类所期望的保持一致。
派生类必须满足基类和客户程序的约定
IS-A是关于行为方式的,依赖客户程序的调用方式
重构
Extract Supper Class
实例
长方形和正方形
依赖倒置原则DIP
a:高层模块不应依赖于底层模块,两者都应该依赖于抽象
b:抽象不应该依赖于细节,细节应该依赖于抽象
原则
如何解释倒置
高层依赖底层,重用变得困难,而最经常重用的就是framework和各个独立的功能组件
高层依赖底层,底层的改动直接反馈到高层,形成依赖的传递
面向接口的编程
实例
Ioc模式
DomainObject / DomianObjectDataService
参考
《敏捷软件开发 原则、模式与实践》
在优化一段sql的时遇到性能问题,sql结构如下
create table #report (...)
insert #report (...)
select ..., fnGetDate(OrderDate) as OrderDate
from ...
where ...
数据量非常小,执行时却发现执行非常慢,大大超过预期。查看执行计划发现table spool/eager spool的时间占了99%,后来发现,如果去掉insert,只执行select,速度相差20倍,就认为这是问题的根源。
想了很多办法来优化速度,比如用表变量替换临时表,直接insert,加top 10000000,用实际的表换掉临时表等等,不见效果。后来逐个字段检查,发现加上OrderDate,性能马上就降下来了。
fnGetDate是一个格式化时间的函数(虽然一般来说格式化的工作不应该在sql中处理,但是这个例子是需要的),目的是把把时间格式化成2004-Nov-01这样格式,后来确定可以应用2004-11-01这种格式,但是有的地方没有改过来,比如这里。
问题找到,把fnGetDate换成convert,速度马上提高20倍。但是问题还不算解决,其他的很多地方都用到了fnGetDate,但是速度没有太大影响,应该还有其他的原因。
后来发现一个现象,加top 10000000与不加两种对比,速度相差7倍,应该还是查询写的有问题,有的地方没有用到索引。经过一番调整后系统恢复正常运行。这时候再把convert换回fnGetDate速度没有太大的变化。
sql server的执行计划虽然会告诉我们我们一个sql执行的详细情况,但是只看表面现象有时候容易差生误导,比如上面的例子,一般来说sql的性能问题大部分由于查询设计的不合理和Index不合理以及资源锁定造成的,发现问题应该首先分析这几方面。
函数确实对性能是有影响的,但是加了函数以后对sql执行造成这么大的影响还是第一次碰到。
sumtec同志也想翻译DDD呀,想翻译DDD的人还真多。
《领域驱动设计——软件核心复杂性应对之道》清华出版社在制作,umlchina上面已经有广告了。
陈大峰,张泽鑫译,问了一下umlchina,最早年底才能面市的说,有对DDD兴趣的话还是先慢慢啃英文版吧。如果想先了解更多,可以看看豆豆他爹的生活随笔,豆豆他爹是审稿者之一。