??xml version="1.0" encoding="utf-8" standalone="yes"?>
虽然|上商店形式多样,每个站点有自q特色,但也有其一般的共?单就"商品的变?以便及时通知订户"q一?是很多网上商店共有的模式,q一模式cMObserver patern.
具体的说,如果|上商店中商品在名称 h{方面有变化,如果pȝ能自动通知会员,是|上商店区别传统商店的一大特?q就需要在商品product中加入Observerq样角色,以便productl节发生变化?Observer能自动观察到q种变化,q能q行及时的update或notify动作.
Java的APIqؓ为我们提供现成的Observer接口Java.util.Observer.我们只要直接使用它就可以.
我们必须extends Java.util.Observer才能真正使用?
1.提供Add/Delete observer的方?
2.提供通知(notisfy) 所有observer的方?
//产品c?可供Jsp直接使用UseBean调用 该类主要执行产品数据库插?更新 private String name; public String getName(){ return name;} } public float getPrice(){ return price;} }
} |
我们注意?在productcM 的setXXXҎ?我们讄?notify(通知)Ҏ, 当Jsp表单调用setXXX(如何调用见我?a target="_blank">另外一文?/font>),实际上就触发了notisfyObserversҎ,q将通知相应观察者应该采取行动了.
下面看看q些观察者的代码,他们I竟采取了什么行?
//观察者NameObserver主要用来对品名U?name)q行观察?br />public class NameObserver implements Observer{ private String name=null; public void update(Observable obj,Object arg){ name=(String)arg; } }
}
//观察者PriceObserver主要用来对品h?price)q行观察?br />public class PriceObserver implements Observer{ private float price=0; public void update(Observable obj,Object arg){ price=((Float)arg).floatValue(); } }
} |
Jsp中我们可以来正式执行q段观察者程?
<jsp:useBean id="product" scope="session" class="Product" />
<jsp:useBean id="nameobs" scope="session" class="NameObserver" />
<jsp:useBean id="priceobs" scope="session" class="PriceObserver" />
<%
}else{
%> //request.getRequestURI()是生本jsp的程序名,是自己调用自己 <input type=hidden name="save" value="1"> </form>
<%
%>
|
执行?span lang="EN-US">JspE序,会出C个表单录入界? 需要输入品名U?产品h, ҎSubmit?q是执行该jsp?br />if (request.getParameter("save")!=null)之间的代?
׃q里使用了数据javabeans的自动赋值概?实际E序自动执行了setName setPrice语句.你会在服务器控制C发现下面信息::
NameObserver :name changet to ?????(Jsp表单中输入的产品名称)
PriceObserver :price changet to ???(Jsp表单中输入的产品h);
q说明观察者已l在行动?span lang="EN-US">.!!
同时你会在执行jsp的浏览器端得C?
产品数据变动 保存! q已l自动通知客户
上文׃使用jsp概念,隐含很多自动动作,现将调用观察者的Java代码写如?
public class Test { public static void main(String args[]){
Product product=new Product();
//加入观察?br />product.addObserver(nameobs);
product.setName("子U了"); }
}
|
你会在发C面信?span lang="EN-US">::
NameObserver :name changet to 子U了
PriceObserver :price changet to 9.22
q说明观察者在行动?span lang="EN-US">.!!
来源 Q?http://book.javanb.com/java-design-patterns/Observer.html
Composite比较Ҏ理解Q想到Composite应该想到树形结构图。组合体内这些对象都有共同接?当组合体一个对象的Ҏ被调用执行时QComposite遍?Iterator)整个树Şl构,L同样包含q个Ҏ的对象ƈ实现调用执行。可以用牵一动百来Ş宏V?o:p>
所?span lang="EN-US">Composite模式使用到Iterator模式Q和Chain of Responsibility模式cM?o:p>
Composite好处
:
1.使客L调用单,客户端可以一致的使用l合l构或其中单个对象,用户׃必关p自己处理的是单个对象还是整个组合结构,q就化了客户端代码?br />2.更容易在l合体内加入对象部g. 客户端不必因为加入了新的对象部g而更改代码?o:p>
如何使用Composite?
首先定义一个接口或抽象c,q是设计模式通用方式了,其他设计模式Ҏ口内部定义限制不多,Composite却有个规定,那就是要在接口内部定义一个用于访问和理Compositel合体的对象们(或称部gComponentQ?
下面的代码是以抽象类定义Q一般尽量用接口interface,
public abstract class Equipment |
抽象c?span lang="EN-US">Equipment是Component定义Q代表着l合体类的对象们,Equipment中定义几个共同的Ҏ?o:p>
public class Disk extends Equipment |
Disk是组合体内的一个对象,或称一个部Ӟq个部g是个单独元素( Primitive)?br />q有一U可能是Q一个部件也是一个组合体Q就是说q个部g下面q有'儿子'Q这是树形结构中通常的情况,应该比较Ҏ理解。现在我们先要定义这个组合体Q?o:p>
abstract class CompositeEquipment extends Equipment //注意q里Q这里就提供用于讉K自己l合体内的部件方法?br /> //上面dIsk 之所以没有,是因为Disk是个单独(Primitive)的元? |
上面CompositeEquipmentl承了Equipment,同时己里面的对象们提供了外部讉K的方?重蝲了Iterator,Iterator是Java的Collection的一个接口,是Iterator模式的实?
我们再看?span lang="EN-US">CompositeEquipment的两个具体类:盘盒Chassis和箱子CabinetQ箱子里面可以放很多东西Q如底板Q电源盒Q硬盘盒{;盘盒里面可以放一些小讑֤Q如盘 软驱{。无疑这两个都是属于l合体性质的?o:p>
public class Chassis extends CompositeEquipment
public class Cabinet extends CompositeEquipment |
x我们完成了整?span lang="EN-US">Composite模式的架构?o:p>
我们可以看看客户端调?span lang="EN-US">Composote代码:
Cabinet cabinet=new Cabinet("Tower");
Chassis chassis=new Chassis("PC Chassis");
//PC Chassis装到Tower?(盘盒装到箱子里)
cabinet.add(chassis);
//一?0GB的硬盘装?PC Chassis (硬盘装到盘盒里)
chassis.add(new Disk("10 GB"));
//调用 netPrice()Ҏ;
System.out.println("netPrice="+cabinet.netPrice());
System.out.println("discountPrice="+cabinet.discountPrice());
上面调用的方?span lang="EN-US">netPrice()或discountPrice()Q实际上Composite使用Iterator遍历了整个树形结?L同样包含q个Ҏ的对象ƈ实现调用执行.
Composite是个很y妙体现智慧的模式Q在实际应用中,如果到树Şl构Q我们就可以试是否可以使用q个模式?o:p>
以论坛ؓ例,一个版(forum)中有很多帖子(message),q些帖子有原始脓Q有对原始脓的回应脓Q是个典型的树Şl构Q那么当然可以用Composite模式Q那么我们进入Jive中看看,是如何实现的.
Jive解剖
在Jive?ForumThread是ForumMessages的容器container(l合?.也就是说QForumThreadcM我们上例中的 CompositeEquipment.它和messages的关pd图:
[thread]
|- [message]
|- [message]
|- [message]
|- [message]
|- [message]
我们?span lang="EN-US">ForumThread看到如下代码Q?o:p>
public interface ForumThread { public void deleteMessage(ForumMessage message)
} |
cMCompositeEquipment, 提供用于讉K自己l合体内的部件方? 增加 删除 遍历.
l合我的其他模式中对Jive的分析,我们已经基本大体理解了Jive论坛体系的框Ӟ如果你之前不理解设计模式Q而直接去看Jive源代码,你肯定无法看懂?br />
:)
来源Q?http://book.javanb.com/java-design-patterns/Composite.html
Path-Specific relationships
The PathProxy solution applies in any situation where an entity can appear as an association of another entity type, but only for a specific path. I refer to such relationships as path specific. E is a child of D, but only for the path A-->B-->C-->D-->E.On another path, D might have no children (A-->B-->Q-->D) or might have a different child or children(A-->B-->X-->D-->Z)
As an example, imagine a development team consisting of a project manager named Johnie and two developers, Robert and Mukunda. On project A, Johnie leads Robert and on Project B, Johnie leads Mukunda. This is a somewhat contrived example, but not an uncommon scenario in the world of corporate structures. In the real world, you might have the efficiency of the same process in different business locations, or the actions taken in response to the same event by different teams
When to use PathProxy?
You have many entities whose interrelationships are complex and require knowledge of other relationships. Creating explicit objects to represent these types of relationships becomes burdensome. This is expecially true if the objects must be persisted, creating a proliferation of database tables.
Consider PathProxy if , Your system design calls for a number of casses whose sole or primary function is to model the relationships between other objects.
Using PathProxy is more complicated than using simple objects to represent relationships, so consider your particular situation. If you have few relationships to store and they are not too complicated, PathProxy may not be the right choice. On the other hand, once you reach a certain level of relationship complexity, using PathProxy will greatly simplify your overall system design. Beijng able to reuse the same machnaism over and over again is also a huge time-saver.
来自 : http://www.javaworld.com/javaworld/jw-07-2008/jw-07-pathproxy.html?page=1