最新评论
BigRain 2011-08-10 08:13
@阿烽
一直关注呢，虽然代码的编写量集聚下降，但不代表技术水平也会下降。
1、装饰者和被装饰者使用的是同一个基类，就是说他们是同一种类型，换句话就是，一个装饰者可能成为另一个装饰者的装饰对象，成为了被装饰者。所以，他们之间的装饰关系充满着不确定性（这个就体现出灵活性）。
2、这边的一般佐料作为第一个被装饰者。装饰者在创建的时候，就必须传入一个被装饰者。而GeneralCondiments就是作为原始的被装饰者。
3、为什么不是面条作为被装饰者呢。装饰者模式中，装饰者可能成为被装饰者，而且并不能确定谁装饰谁。如果面条和粥也继承自CondimentsDecorator，那这两种食物相互装饰会如何呢？很显然是不妥的。这个可以参考.net中Stream的设计。
4、像你说的上述的业务情况，我可能会让面条和粥继承一个"主食"，再使用策略模式，让 装配好的装饰者 成为"主食"的一个策略。
阿烽 2011-08-09 20:50
啊哈，
建雨重新走技术路线了，好事啊
说说我看这个装饰者模式的看法，
1、既然采用装饰者模式当然是为了解决被装饰者和装饰者之间的组合导致的子类太多难以维护的问题；
2、例子举得有点偏差，不容易被理解，这里看起来被装饰的是一般调料。。
3、装饰者是面条 如果能和被装饰者共同继承与一个类 如食物，那么扩展性会大大增加，呵呵 就可以扩展出海鲜粥 、牛肉饺子的东西啦 ；
一家之言
BigRain 2010-09-29 18:29
@肖敏
1、对于第一点，GetNumberString只是客户端代码，负责装配链条和触发这个职责链。并没有和具体的逻辑发生耦合。（总要有个地方进行链条的装配，这个装配的逻辑是有客户代码决定的）。对于第二点，这个链条的装配是没有错的。
2、我们的分歧实际上是，一条职责链是否只能有一个节点来处理（只有上一个节点处理不了，才交由下一个节点处理）。我查了下资料，没有发现说职责链只能被一个节点处理。有多个的对象可以处理一个请求，哪个对象处理该请求运行时刻自动确定，从这句话来理解的话，也就是说请求可以同时被多个节点处理。很多的例子都展示了请求只能被一个节点处理。
3、如果一个请求只能由一个节点来处理。我承认你说的是对的。本来亿这个节点应该就能全部处理了（就是要完成亿和亿以下的处理），如果这个数不到亿，才会交由万来处理。只是这样就加剧了亿和万的耦合，换句话说，在实现时，是一个高耦合的过程，所以进行了适当的变异。
4、上面的这个例子，从意图上说他应该是职责链，但就是实现的外在表现，或许可能用监听者模式，但很显然不具备这个意图。我个人觉得是否是某种模式，主要看这段程序所要实现的意图。
肖敏 2010-09-25 08:44
博主这里例子不能体现职责链模式的特点。
使多个对象都有机会处理请求，从而避免请求的发送者和接收者之间的耦合关系。将这些对象连成一条链，并沿着这条链传递该请求，直到有一个对象处理它为止。
1.避免请求的发送者和接受者的耦合关系。而博主的GetNumberString()方法（客户端代码）跟所有的接收者都是紧耦合。
2.将这些对象连成一条链，并沿着这条链传递该请求，直到有一个对象处理它为止。
这里强调的是，该请求被一个对象处理。而博主的例子是该请求可能被所有的接收者处理（并且分解）。当然，这点可以不必太拘泥。但是第一点是致命的。
通常职责链的典型例子是窗口事件的分发(Event bubble)，比如说MouseMove事件。而MouseMove的响应函数是请求的处理者。在设计窗口类的时候，设计者并不知道该窗口会有什么控件，什么控件会有处理函数。因此会采用职责链的方式把窗口消息分发给自己的子控件，子控件判断是否有处理函数，如果没有则再次分发给自己的子控件。
另外IHttpHandler也不是使用的职责链模式，它只是一个接口。也许博主想说的是aspx的事件模型（Init-Load-PreRender-Render。 此处只是示例，并没列出所有事件）使用的是职责链模式，其实它只是一个pipeline。流水线处理的方式并不完全等同于职责链模式。其实在这里，aspx的事件模型更像是模板方法或者是builder模式，或者两者兼而有之。职责链的特点除了第一点提到的，发送者跟接收者不能耦合以外，请求的处理者又是请求的转发者。而在aspx事件模型中根本不是这种情况。
勤思好学 2010-04-16 15:35
博主你好！！请问您一下就是用MODEM实现来电显示程序时，要怎样才能知道未接电话和已接电话？？使用的是serialport控件！！请博主指教指教！谢过博主！！ weixiang27114@126.com 这是我的邮箱，谢谢！！！