前几天，网上找了套java题目，给项目组成员做了一次考试，意图是让大家知道很多基础概念还不一定清楚，于是应该good good study，day day up。
考试之后，有同事问起一个“by value”知识点相关的题目：
Given the following code:
public class Test{
public static void main(String args[])
{
S ...
Bad Smells & Refactoring
以前做的一个培训，当时备课时还是花了一些工夫。ppt贴不上来，把备课稿贴在这，备份一个吧。
Bad Smells & Refactoring
1 题记
Any fool can write code that a computer can understand. Good programmers write code that humans can understand.——Martin Fowler
（任何一个傻瓜都能写出计算机可以理解的代码。唯有写出人类容易理解的代码，才是优 ...
Divergent Change(发散式变化)
指的是“某一个类受到多种变化的影响”，A/B/C/D……多种功能变化的时候它都需要修改。
病因大致是某个类负担了多项任务，太操心了。很可能需要再拆分几个类出来，把变化封装得更细。
以前我写代码的时候有一个例子，曾经有一段时间，P_Unit类处理所有BSC单元的逻辑，但各种单板的逻辑是不一样的，于是DTB改逻辑的时候要修改P_Unit、ABPM改的时候要修改P_UNit、甚至HDLC/UID等逻辑修改的时候P_Unit都要改。显然该类管得太多了。后来，我看了<重构>这本书，痛下决 ...
Bridge模式讲的是把抽象部分和实现部分隔离开，能够实现相互独立发展。
我对Bridge模式依然理解得不是很深入，我盼望书中给我一个简单、清晰的例子来说明该模式的应用，但书本没有能够让我满意，当然也可能是我的问题。
而且，书中的Airplane/AirplaneMaker这个例子放在这里说明Bridge是不恰当的。
Airplane和AirplaneMaker并不能代表Bridge模式中需要的抽象部分和实现部分。这个例子用来说明合成/聚合复用原则还是比较合适的，而且AirplaneMaker和Airplane的关系与“职务”与“员工”的关 ...
这个模式还是比较有用的，用于解开模块之间的复杂耦合。
从道理上讲，符合“内部高内聚、外部松耦合”的要求。从实际操作上，各个模块经常分开开发、分开维护，于是使用Facade定义清晰接口，只访问一个门面类，显然好过模块之间的多个类之间的交叉依赖、关联。
该模式的中英文名称之间不是直接翻译的，但表达了这个模式的两个特征，轻量级、共享。
我理解，Flyweight模式就是为系统中需求数量多、但状态不多的轻量级对象建立一个共享实例池。
思路比较容易理解。就不多说了。
大家越来越像了……
从实现形式上看，Decorator模式与Proxy模式之间的区别不大，但从用意上看，前者是想增强方法本身功能、后者是想控制所包含对象的动作。
Proxy模式的一个例子是书中的，在request方法前后增加pre、post方法来做额外工作。
原始类、Proxy类都实现相同的接口，在做了可插入性考虑的系统，Proxy类就可以以原始类的身份被插入系统，原始类的动作就可以被控制，比如在动作之前判断权限、在动作之后记录日志等等。
越来越体会到合成/聚合复用原则的应用。
越来越体会到可插入性的重要。
外部接口没有变化，但内部实现“偷偷”变化了。其实也不是“偷偷”，更应该光明正大地告诉人家，你是经过装饰的，虽然都有“显示鼻子”的接口方法，但你的鼻子可能是垫了东西的。
需要注意的是，修饰过的类和被修饰的类是同类的。比如，实现相同的接口。
装饰过的类要拥有一个未被装饰类的属性。即关联关系。（合成还是聚合我就懒得区分了。）
装饰过的类的方法通常要在未被装饰类的方法基础上做点手脚，以体现装饰。
顺着脑子想到的一个例子，接口PriceGetter，定义了一个方法int getPrice()。
CommonPriceGet ...
个人感觉Composite模式是一个比较牛X的模式。完美地实现了“树”这一现实实体在OO软件世界的映射。
此模式巧妙之处在于，树叶和枝干实现了同一接口，但树干同时是装载该接口实现类实例的容器，树干可以容纳树叶、同时也可以再容纳树干，于是，一棵数就完美地被描绘出来了。
一个比较典型的例子就是，界面上的Panel是容器的同时、也是控件，可以容纳控件的同时也可以再容纳容器（这里说得就比较罗嗦了，容器本身就是控件嘛）。
但需要注意的是，容器对接口方法的实现需要自律，通常是遍历调用容器内容纳的接口实现类实例的同名方法。
JUnit架构中也有Composite模式的完美应用 ...
我觉得把Default Adapter模式和Adapter模式割裂开来，不会影响对Default Adapter模式的理解。
Default Adapter模式就是为目标接口提供一个平庸实现层，真正的实现类从此平庸实现层继承，Override其中对自己有意义的方法，而其他方法保持其平庸状态。
为Target接口所需的方法统统提供一套缺省实现，通常的做法是，除非你特别要求，否则我什么都不做。
如果实现类比较多而且需要实现的方法很多、真正做事儿的方法很少，那么Default Adapter模式会为系统省下不少重复代码。
我对Adapter模式的理解是：
某处有一些需求，可体现为Target接口（不妨假定Target有两个方法，m1、m2）。
我们在满足该需求的时候，即构造类来实现Target接口的时候，很容易想到的是看看是否存在已有资源可被利用（重用）。
比方说，此时我们发现Adaptee类实现了方法m1，如何重用？
两种重用方式分别对应于Adapter模式的两种形态：
1 继承的方式——类的Adapter模式
Adapter类从Adaptee类继承，于是自然拥有了方法m1。再自行实现方法m2，便完成了对Target接口的实现。
2 合成/聚合的方式—&m ...
周末再翻《Java与模式》，说说对创建类模式的一点理解。大家交流。
创建类模式，我主要关注的是Simple Factory、Factory Method、Builder这几个。
当然，其他一些模式可能更加常用，比如Singleton、Prototype，但比较简单，不涉及整体脉络，此处略去不述。
首先，说说Simple Factory。
创建类模式，都是对实例创建过程的封装。
Simple Factory，是最容易想到的封装方式，Client无需知道某类的instance是怎么弄出来的，直接跟工厂要实例就行了，而且是静态方法，调用起来也方便。此时，工厂(书中叫做Creator)挑起重 ...
以前写邮件的时候，很多同事都说软件产品的质量属性太多。
周末重看《Java与模式》，发现阎宏博士的一些简短归纳，感觉有些道理，可作参考。
阎宏认为，比较重要的质量属性为可维护性和可重用性。可维护性又分为：可扩展性、灵活性、可插入性。
我认为，可维护性，分为：可读性、可扩展性、可修改性、可插入性，将更加圆整、更加容易理解。
首先，代码要可读，可读才可理解，可理解才可维护。其余的可扩展性、可修改性、可插入性是对系统增加新零件、修改原有零件、更换原有零件的支持，支持了这三种对系统的维护方式，系统当然就可维护了。
另外，我觉得还有一个比较重要的质量属性，是可测试性。不过，怎么样才更加可测试？ ...
Open-Close原则
是一个愿景性质的原则，如果系统能够达到Open-Close原则描述的情形就比较理想了，对扩展开放、对修改关闭，即，不修改原有代码即可完成对系统的扩展。
实现Open-Closed原则，抽象化是关键。
抽象层，因为抽象所以稳定。不变应万变，不用修改，满足Open-Closed原则的Closed一头。
抽象层的具体实现层可以满足扩展要求，满足Open-Closed原则的Open一头。
Open-Closed原则还可表述为“对可变性的封装”原则。“找到一个系统的可变因素，将它封装起来。”
一个可变性因素，不应该被散 ...
王杲杲
- 浏览: 27168 次
- 详细资料
搜索本博客
最近加入圈子
最新评论
-
“学习OO好榜样”之软件质 ...
《Java与模式》中前几章详析了对象设计的原则与方法！
-- by pdw2009 -
“学习OO好榜样”之软件质 ...
关于如何设计低耦合的系统，建议看看《敏捷软件开发：原则、模式与实践》。
-- by yiding_he -
“学习OO好榜样”之软件质 ...
设计模式确实是学习和领悟oo的好东西
-- by Calmfeeling -
“学习OO好榜样”之软件质 ...
这个只能叫做源代码质量属性
-- by gurudk -
“学习OO好榜样”之面向对 ...
都是理论的东西了，能不能结合实际的说一说呢？
-- by spiritfrog
评论排行榜