`
王杲杲
  • 浏览: 44377 次
最近访客 更多访客>>
社区版块
存档分类
最新评论
文章列表
《论语》中有一句话:自古皆有死,民无信不立。 “民无信不立”是什么意思?于丹教授说是,人民对国家失去信仰,国家就会崩溃和涣散。 用的是“信仰”这个词儿。 曾经有一阵子,经常看文章“信仰”来“信仰”去地说事儿,我当时不知道“信仰”是个什么东东,现在好像也只知道个大概。 对于“民无信”这句话,我宁可理解为,人民对国家失去“信任”。 这不是一句废话么? 就好像《南都》一篇文章,说,贤臣劝说君王要“亲君子远小人”而没有随文附带一套君子小人鉴定器,就同样是废话,而且非常可气。 不是实际做事儿的人经常喜欢站在旁边说废话,好像还很有使命感,很难忍住不说。
前几天,网上找了套java题目,给项目组成员做了一次考试,意图是让大家知道很多基础概念还不一定清楚,于是应该good good study,day day up。 考试之后,有同事问起一个“by value”知识点相关的题目: Given the following code: public class Test{     public static void main(String args[])     {         String str=new String(World);         char ch[]={'H','e','l','l','o'};         change ...
<我的美国舅舅> 一扫<去年在马里昂巴>给我留下的对 阿伦雷奈 的沉闷印象。 冷峻、干练、犀利。 <我想要回家> 片中英语、法语混杂,只有法语字幕,我英语水平又只有这么凑合,于是没有看完。除了记得看过一点 ...
媳妇喜欢小津的调调 周末看片的时候发现小津的片子散装套装都悉数看过 找个差不多类型的吧 李安的有么 小房间已经很凌乱 成濑巳喜男的套装恰好放在挺显眼的位置还没有开封 我向来喜欢依循时间顺序 于是打开<浮云>   印象里是成濑的名作 今天查了一下果然 日本人把<浮云>排在百部佳作第二名足见其地位   氛围和情绪营造很纯厚 怪不得王家卫关锦鹏许鞍华都喜欢 这几位也都是习惯于把大块大块情绪塞满整个放映时间尤其是王家卫   <浮云>中人物树立丰满可成为一派典型 今后可以说这个人真雪子那个人真富冈 当然观者一定是不齿富冈叹惋雪子我也是 浮云啊浮云片中谁是浮云呢 光是雪子 ...
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 u ...
Divergent Change(发散式变化) 指的是“某一个类受到多种变化的影响”,A/B/C/D……多种功能变化的时候它都需要修改。 病因大致是某个类负担了多项任务,太操心了。很可能需要再拆分几个类出来,把变化封装得更细。 以前我写代码的时候有一个例子,曾经有一段时间,P_Unit类处理所有BSC单元的逻辑,但各种单板的逻辑是不一样的,于是DTB改逻辑的时候要修改P_Unit、ABPM改的时候要修改P_UNit、甚至HDLC/UID等逻辑修改的时候P_Unit都要改。显然该类管得太多了。后来,我看了<重构>这本书,痛下决心做了重构。想起来03年,徐峰做配置CAF的时候建议我每个板 ...
Bridge模式讲的是把抽象部分和实现部分隔离开,能够实现相互独立发展。 我对Bridge模式依然理解得不是很深入,我盼望书中给我一个简单、清晰的例子来说明该模式的应用,但书本没有能够让我满意,当然也可能是我的问题。 而且,书中的Airplane/AirplaneMaker这个例子放在这里说明Bridge是不恰当的。 Airplane和AirplaneMaker并不能代表Bridge模式中需要的抽象部分和实现部分。这个例子用来说明合成/聚合复用原则还是比较合适的,而且AirplaneMaker和Airplane的关系与“职务”与“员工”的关系比较类似,实际上,后一个例子也是出自于合成/聚合复用原 ...
这个模式还是比较有用的,用于解开模块之间的复杂耦合。 从道理上讲,符合“内部高内聚、外部松耦合”的要求。从实际操作上,各个模块经常分开开发、分开维护,于是使用Facade定义清晰接口,只访问一个门面类,显然好过模块之间的多个类之间的交叉依赖、关联。
该模式的中英文名称之间不是直接翻译的,但表达了这个模式的两个特征,轻量级、共享。 我理解,Flyweight模式就是为系统中需求数量多、但状态不多的轻量级对象建立一个共享实例池。 思路比较容易理解。就不多说了。
大家越来越像了…… 从实现形式上看,Decorator模式与Proxy模式之间的区别不大,但从用意上看,前者是想增强方法本身功能、后者是想控制所包含对象的动作。 Proxy模式的一个例子是书中的,在request方法前后增加pre、post方法来做额外工作。 原始类、Proxy类都实现相同的接口,在做了可插入性考虑的系统,Proxy类就可以以原始类的身份被插入系统,原始类的动作就可以被控制,比如在动作之前判断权限、在动作之后记录日志等等。 越来越体会到合成/聚合复用原则的应用。 越来越体会到可插入性的重要。
外部接口没有变化,但内部实现“偷偷”变化了。其实也不是“偷偷”,更应该光明正大地告诉人家,你是经过装饰的,虽然都有“显示鼻子”的接口方法,但你的鼻子可能是垫了东西的。 需要注意的是,修饰过的类和被修饰的类是同类的。比如,实现相同的接口。 装饰过的类要拥有一个未被装饰类的属性。即关联关系。(合成还是聚合我就懒得区分了。) 装饰过的类的方法通常要在未被装饰类的方法基础上做点手脚,以体现装饰。 顺着脑子想到的一个例子,接口PriceGetter,定义了一个方法int getPrice()。 CommonPriceGetter是实现该接口、正常计算价格的。而95DiscountPriceGetter也实 ...
个人感觉Composite模式是一个比较牛X的模式。完美地实现了“树”这一现实实体在OO软件世界的映射。 此模式巧妙之处在于,树叶和枝干实现了同一接口,但树干同时是装载该接口实现类实例的容器,树干可以容纳树叶、同时也可以再容纳树干,于是,一棵数就完美地被描绘出来了。 一个比较典型的例子就是,界面上的Panel是容器的同时、也是控件,可以容纳控件的同时也可以再容纳容器(这里说得就比较罗嗦了,容器本身就是控件嘛)。 但需要注意的是,容器对接口方法的实现需要自律,通常是遍历调用容器内容纳的接口实现类实例的同名方法。 JUnit架构中也有Composite模式的完美应用,TestCase是Test、Te ...
我觉得把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 合成/聚合的方式——对象的Adapter模式 Adapter拥有一个Adap ...
周末再翻《Java与模式》,说说对创建类模式的一点理解。大家交流。 创建类模式,我主要关注的是Simple Factory、Factory Method、Builder这几个。 当然,其他一些模式可能更加常用,比如Singleton、Prototype,但比较简单,不涉及整体脉 ...
Global site tag (gtag.js) - Google Analytics