摘要： 软件中的Barrier.数据从程序移到DB中时,要跨越数据库的Barrier.消息从一个PC到另一个PC时,要跨越网络Barrier.跨越可能是复杂的,很可能处理Barrier的Code会多于处理本来要解决的问题的Code.Proxy模式.DB和ProductIMP这两个协作对象互相不可见.Proxy负责连接两者.这样,Proxy模式跨越了Barrier,而且不会影响到任何一个参与者.关注点分离:业务逻辑和数据库.Proxy变成了一个很重的点,Application和API的映射集中在Proxy上,两者的改变都会导致Proxy更改.[Agile Software Development(Pri 阅读全文

摘要： 简易的台灯Abstract Server模式谁拥有接口.接口属于它的客户,而不是它的派生类.接口和客户之间的逻辑关系,强于接口和其派生类的逻辑关系.逻辑关系和实体关系的强度是不一致的.在实体关系上,继承比依赖更强.最好将接口和它的客户打包,而不是和它的派生类在一起.Adapter模式当Light不能继承Switchable接口时(第三方代码).Modem Client仍然看到的是期望的连接行为,而Ded User不必去调用根本无用的Dial/Hangup().仍然存在杂凑体.Adapter仍然要模拟连接动作.但是依赖关系都存在于Adapter上,其对User是隐藏的.只有factory才会依赖 阅读全文

摘要： 拉模式.Observer实现了一种间接关系.可以向各种对象注册观察者.可以有效地管理依赖关系.拉模式实现简单,且Subject和Observer可以成为类库中的可重用元素.当被观察对象比较复杂,并且Observer需要一个提示,那么使用推模式.该模式的目的:增加新的Observer对象时,无需更改被观察的对象.被观察对象保持了封闭.OCP.模式的形成.朝着正在编写的代码的需要方向去演化代码.在重构代码以解决耦合性,简单性,以及表达性的问题时.代码可能已经接近于一个特定的模式了.重命名类和变量的名称,并修改结构以符合更正规的模式形式,这样,代码回归为模式.优先考虑测试,有助于将设计中的耦合减至最 阅读全文

摘要： [Agile Software Development(Principles,Patterns,and Pracitices)] 阅读全文

摘要： 使用new的Code都违反了DIP.但是,依赖于稳定的具体类,是无害的.例如string.另一方面,对于正在开发中的APP,很多具体类是易变的.此时应该依赖于抽象接口.Factory模式:只依赖于抽象接口就能创建出具体对象的实例.对Test Fixture使用工厂编写UT时,希望把一个模块和它使用的模块隔离起来,从而单独测试该模块的行为.工厂的使用遵循DIP,对于系统中所有的易变类都要使用工厂.但是,工厂是复杂的,为了创建一个新类,需要1个表示该类的接口和1个其工厂的接口.实现这两个接口的具体类.使得高层决策模块在创建类的实例时无需依赖这些类的具体实现.使得一组类的完全不同系列的实现间进行切换 阅读全文

摘要： 包的设计.通过把类组织成package,可以在更高层次的抽象上理解设计.通过包来管理软件的开发和发布.由于类之间的相互依赖关系,包之间会产生依赖关系.包的依赖关系展示了APP的高层组织结构.粒度:内聚性."自顶向上"的将类划分到包中Reuse-Release Equivalence Priciple(REP).重用的粒度就是发布的粒度.重用类库时,我们要求author维护Code,同时在接口和功能改变时通知我们(同时我们有拒绝改变的权利).重用性必须基于包,可重用的包必须包含可重用的类.包中的所有类应该对于同一类用户来说都是可重用的.Common-Reuse Princip 阅读全文

摘要： 去除代码中的if(obj==null),或者try/catch语句.维持Code的一致性.Null对象,代表"什么也不做"的一个对象.使Null对象称为一个匿名内部类确保了该类只有单一实例.并且客户无法创建Null对象的其他实例.可以使用if(obj== Employee.Null)表达.[Agile Software Development(Principles,Patterns,and Pracitices)] 阅读全文

摘要： 类和实例对于大多数的类,都可以创建多个实例.在需要和不需要时,创建和删除这些实例.该过程会伴随着内存的分配和归还.同时,有一些类,应该仅有一个实例.该实例在程序启动/结束时被创建和删除.root对象.通过该对象可以得到系统中的其他对象.factory对象.用来创建系统中的其他对象.manager对象.负责管理和控制其他对象.对于这些对象,如果创建了多份,那么就会发生逻辑错误.通常情况下,强制对象单一性的机制有些多余.完全可以在程序启动时只创建该对象的一个实例.不过,使用模式能够传达我们的意图(该类仅能有一个实例).代价/收益:如果强制对象单一性的机制是轻量级的.那么传达意图的收益会胜过实施这些 阅读全文

摘要： 相同的目的:把某种策略施加到另一组对象上.Facade从上面施加策略.其使用是明显且受限的.当策略涉及范围广泛并且可见时.约定的关注点.都同意使用Facade而不是隐藏于其下的对象.Mediator从下面施加策略.其使用不明显且不受限.当策略隐蔽且有针对性时.Mediator对用户是隐藏的.其策略是既成事实而不是一项约定.Facade模式Mediator模式[Agile Software Development(Principles,Patterns,and Pracitices)] 阅读全文

摘要： 继承program by difference.通过继承,可以建立完整的软件结构分层.其中每一层都可以重用该层次以上的Code.过度使用继承的代价是巨大的.应使用组合或者委托来替代继承.Template Method(使用继承)和Strategy(使用委托)模式解决了相同的问题:分离通用的算法和具体的上下文(DIP).Template Method模式.Strategy模式Template Method模式允许一个通用算法操纵多个可能的具体实现.而完全遵循DIP的Strategy模式,允许每一个具体实现都可以被多个不同的通用算法操纵.总结.两者都用来分离高层算法和底层的具体实现.都允许高层算法 阅读全文