foxox

hibernate，spring，webwork，struts，jfreechart，ireport， oscache,quartz,freemaker,whirlycache,proxool,dbcp,c3p0,cewolf, je-analysis,mail,junit,acegi-security,dom4j,log4j,ehcache,xul, classloader 虚拟机内存分配(jm

应用场景： 一个使用command类的sensor类。 现在程序要做扩展，一个sensor类要调用0-*个command类。 不修改代码，做扩展。 具体的方法： command类派生一个子类。 compositeCommand包含0-*个command， 问题解决。。。。。 注意事项： 1.它能把“一对多”变成“一对一” 2.command必须是类型相似，平等对待的对象。没有层次的划分。 3.图的

对于控制和实现，这三个模式体现着三个不同的层次，如果加上不使用任何模式，就是有四个层次了。 这里所说的层次，没有高低之分，只有需求的区分。如果对于一个没有任何变化的需求，而使用上Bridge模式，也同样是一个丑陋的设计。 什么是控制和实现？抄一个《ASD》中的例子，一个照明设备（灯），他有两部分。一个是开关，一个是灯泡。开关有两个操作，开和关。灯泡也有两个操作，发光或不发光。 最简单的控制和

1.领域对象的独立性？？？   dao，网络，UI，事务，文件操作等等。。。。   领域对象上面是UI 下面是dao，文件，事务，等辅助类。基础类。   如何做到干干净净？？？ 2.分层策略对领域对象的独立性有多大好处，层之间的沟通原则？？ 3.设计模式对领域对象的独立性有多大好处，怎么用设计模式不多不少正好？？？ 4.服务的概念对领域对象的独立性有多大好处??   服务是更多对象的链接点。依附于

敏捷开发的几个大的原则 1.单一职责 srp 2.开放-封闭 ocp 3.liskov替换原则 lsp ？ 4.依赖倒置 dip 5.接口隔离 isp 敏捷开发提倡简单设计的实践，“并在实现新需求时抓住机会改进设计”以对同类性质的改动封闭，做到由需求的变化驱动设计的进化（我们不能因为设计的退化而责怪需求的变化），同时经验在此起到十分重要的作用，如有经验的设计人员可以凭经验在初始设计时做出必要

应用场景： subject （父类） Timesource  （接口） mockTimesource （实现类） observer（接口） MockTimesink （实现类） 模拟的是一个定时器，到固定的时间，触发update事件，调用所有注册过这个事件的类的update方法。。。 具体的实现： junit的testcase： 看图吧。 呵呵。。。 里面有一句话，很值得学习： 我们不是把时间传给

应用场景： 简易的台灯包括: 1.switch (开关) 2.light(灯) 原来是两个类。 把模式加上： switch(开关) light(灯) switchable(开关接口，灯来实现) 注意事项： 谁拥有这个接口？？ 接口属于它的客户，而不是他的派生类。 客户和接口之间的逻辑绑定关系，要强于接口和他的派生类之间的逻辑绑定关系。

应用场景： 1.搞一个接口 order 2.搞一个实现类 orderImp 3.搞一个代理类 orderproxy 为什么这么搞： 我的理解 假设场景：你现在要把order的信息存储到数据库中 4.搞一个db类 数据库的操作代码会和具体的业务逻辑放到一起。 加了一层代理 orderproxy 1.首先由一个id（图2） 2.然后实现order接口。order里面的接口都要实现。 在具体的方法里面实