|
精华帖 (1) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (8)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2011-06-01
最后修改：2011-06-01
kakaluyi 写道 每个state类持有相同的context的引用，
下面是一个BlueState类，由回调context来实现状态转换（但是状态转换的逻辑封装在context类中，你赞同回调也是控制反转，这边也是回调呀） public class BlueState extends State{ public void handlepush(Context c){ //根据push方法"如果是blue状态的切换到green" ; c.setState(new GreenState()); } public void handlepull(Context c){ //根据pull方法"如果是blue状态的切换到red" ; c.setState(new RedState()); } public abstract void getcolor(){ return (Color.blue)} } 所以我给你指出你的这句话： 引用 状态模式由自己控制状态变化交给了context类 是错的，你把反转的方向搞错了，我给你的回复是：
引用 这个是错误的，刚好相反，如果我们使用if-else/switch-case的话，相当于使用了context控制所有的状态变化逻辑和变化后相应的行为，我们使用状态模式，就是把这二者封装给了状态而不是context，请参见漫谈设计模式和GoF设计模式的状态模式章节。
特别是请理解这句话 引用 我们使用状态模式，就是把这二者封装给了状态而不是context 。修行在个人，看造化了。
|
| 返回顶楼 | |
|
发表时间：2011-06-01
最后修改：2011-06-01
redhat 写道 kakaluyi 写道 引用 给你举例说明下，Spring的ORM框架，主要是使用了模板方法模式，使我们更好方便的使用，我们只要把处理查询结果回调交给HibernateTemplate类(或者相应的template)即可，至于什么时间调用你的回调，都交给了这些template类，这即是控制的反转。
我怎么觉得这是门面模式呢，不要看到templete就以为用到了模板模式，模板模式比如servlet提供init,dopost,doget,destroy方法，你可以重写，也可不重写。模板方法是搭好框架由我们继承实现，参考listenr,structs的action。 其他真的关于模式真的有很多不同的见解，不过人是活的，模式只是站在别人的经验上看问题，有争论时正常的。特别是控制反转这种抽象的概念，国外大牛之间都有conflict，不要违反基本原则就好 这个我就不再说明了，以我的观点再看，你没有理解什么是模板方法模式，请参见漫谈设计模式第2章。 目前我没有找到一个人说HibernateTemplate不是使用模板方法模式的，这个请参见spring orm相关的资料，rod大叔的那两本书里应该说明的很清楚了。 我们说明问题应该严谨，这也是为什么我常碰见老外讲的技术很严谨，很多人中国人没理解就乱说一气的，我曾经碰见一个人指着模板方法模式说是command模式的，指鹿为马呀！不应该有这种讨论存在的 其实设计模式模式相当复杂的，很多人不可能1-2年对那些基本的23种模式（抛去那些不常用的）完全掌握的，可以说80%以上的只是了解定义和它讲述的故事而已，我碰见很多架构师对模式理解的一塌糊涂的（当然都是中国的架构师，不是自我鄙视中国人），国外很多论坛上，他们所描述的才感觉“英雄所见略同”。 我发现，你是不是不明白控制调用的反转才导致理解上的出入。模板方法模式如何实现控制反转的，可以参见gof的设计模式和我的书籍IoC方面的解释（也就是本贴的内容）。 不管有什么争论也好，驴子不是马，这个模式没有使用到IoC就没有使用到，你理解了就会明白它没有使用到还是使用到，目前至少关于这方面争论的话题都没有看到是争论状态模式使用了反转控制的（要说反转控制，是不严格的，因为状态之间可以不切换的，所以对于状态的设置也未反转到某些state对象里），我们应该争论驴子应该拉磨还是应该拖粮食这才有意义。 引用 我们更好方便的使用，我们只要把处理查询结果回调交给HibernateTemplate类(或者相应的template)即可 内部spring hibenatetemple实现确实是实现模板方法，你把我们的使用hibernateTemplate的方式也叫做模板方法我真的怀疑你对模板的理解。
这个是我写给公司同事分享，关于模板方法的 对于用户使用抽象使 定义了一个或多个抽象操作，以便让子类实现。这些抽象操作叫做基本操作，它们是一个顶级逻辑的组成步骤。 （AbstractClass）角色有如下的责任： 定义并实现了一个模版方法。这个模版方法一般是一个具体方法，它给出了一个顶级逻辑的骨架，而逻辑的组成步骤在相应的抽象操作中，推迟到子类实现。顶级逻辑也有可能调用一些具体方法。 具体模版（ConcreteClass）角色有如下的责任： 实现父类所定义的一个或多个抽象方法，它们是一个顶级逻辑的组成步骤。 每一个抽象模版角色都可以有任意多个具体模版角色与之对应，而每一个具体模版角色都可以给出这些抽象方法（也就是顶级逻辑的组成步骤）的不同实现，从而使得顶级逻辑的实现各不相同。 |
| 返回顶楼 | |
|
发表时间：2011-06-01
redhat 写道 kakaluyi 写道 每个state类持有相同的context的引用，
下面是一个BlueState类，由回调context来实现状态转换（但是状态转换的逻辑封装在context类中，你赞同回调也是控制反转，这边也是回调呀） public class BlueState extends State{ public void handlepush(Context c){ //根据push方法"如果是blue状态的切换到green" ; c.setState(new GreenState()); } public void handlepull(Context c){ //根据pull方法"如果是blue状态的切换到red" ; c.setState(new RedState()); } public abstract void getcolor(){ return (Color.blue)} } 所以我给你指出你的这句话： 引用 状态模式由自己控制状态变化交给了context类 是错的，你把反转的方向搞错了，我给你的回复是：
引用 这个是错误的，刚好相反，如果我们使用if-else/switch-case的话，相当于使用了context控制所有的状态变化逻辑和变化后相应的行为，我们使用状态模式，就是把这二者封装给了状态而不是context，请参见漫谈设计模式和GoF设计模式的状态模式章节。
特别是请理解这句话 引用 我们使用状态模式，就是把这二者封装给了状态而不是context 。修行在个人，看造化了。引用 ），状态的互相转化没有反战控制，可能你在这些模式里做了些变化实现了控制反转，但是一般我们不认为是。
这句话是你说的吧，我只是把反转关系写错了，但是你是把整个概念完全理解错了，算了，感觉你自以为是个牛人，我也自以为是个牛人，到底谁是牛人我都觉得不重要 |
| 返回顶楼 | |
|
发表时间：2011-06-01
kakaluyi 写道 redhat 写道 kakaluyi 写道 引用 给你举例说明下，Spring的ORM框架，主要是使用了模板方法模式，使我们更好方便的使用，我们只要把处理查询结果回调交给HibernateTemplate类(或者相应的template)即可，至于什么时间调用你的回调，都交给了这些template类，这即是控制的反转。 我怎么觉得这是门面模式呢，不要看到templete就以为用到了模板模式，模板模式比如servlet提供init,dopost,doget,destroy方法，你可以重写，也可不重写。模板方法是搭好框架由我们继承实现，参考listenr,structs的action。 其他真的关于模式真的有很多不同的见解，不过人是活的，模式只是站在别人的经验上看问题，有争论时正常的。特别是控制反转这种抽象的概念，国外大牛之间都有conflict，不要违反基本原则就好 这个我就不再说明了，以我的观点再看，你没有理解什么是模板方法模式，请参见漫谈设计模式第2章。 目前我没有找到一个人说HibernateTemplate不是使用模板方法模式的，这个请参见spring orm相关的资料，rod大叔的那两本书里应该说明的很清楚了。 我们说明问题应该严谨，这也是为什么我常碰见老外讲的技术很严谨，很多人中国人没理解就乱说一气的，我曾经碰见一个人指着模板方法模式说是command模式的，指鹿为马呀！不应该有这种讨论存在的 其实设计模式模式相当复杂的，很多人不可能1-2年对那些基本的23种模式（抛去那些不常用的）完全掌握的，可以说80%以上的只是了解定义和它讲述的故事而已，我碰见很多架构师对模式理解的一塌糊涂的（当然都是中国的架构师，不是自我鄙视中国人），国外很多论坛上，他们所描述的才感觉“英雄所见略同”。 我发现，你是不是不明白控制调用的反转才导致理解上的出入。模板方法模式如何实现控制反转的，可以参见gof的设计模式和我的书籍IoC方面的解释（也就是本贴的内容）。 不管有什么争论也好，驴子不是马，这个模式没有使用到IoC就没有使用到，你理解了就会明白它没有使用到还是使用到，目前至少关于这方面争论的话题都没有看到是争论状态模式使用了反转控制的（要说反转控制，是不严格的，因为状态之间可以不切换的，所以对于状态的设置也未反转到某些state对象里），我们应该争论驴子应该拉磨还是应该拖粮食这才有意义。 引用 我们更好方便的使用，我们只要把处理查询结果回调交给HibernateTemplate类(或者相应的template)即可 内部spring hibenatetemple实现确实是实现模板方法，你把我们的使用hibernateTemplate的方式也叫做模板方法我真的怀疑你对模板的理解。这个是我写给公司同事分享，关于模板方法的 对于用户使用抽象使 定义了一个或多个抽象操作，以便让子类实现。这些抽象操作叫做基本操作，它们是一个顶级逻辑的组成步骤。 （AbstractClass）角色有如下的责任： 定义并实现了一个模版方法。这个模版方法一般是一个具体方法，它给出了一个顶级逻辑的骨架，而逻辑的组成步骤在相应的抽象操作中，推迟到子类实现。顶级逻辑也有可能调用一些具体方法。 具体模版（ConcreteClass）角色有如下的责任： 实现父类所定义的一个或多个抽象方法，它们是一个顶级逻辑的组成步骤。 每一个抽象模版角色都可以有任意多个具体模版角色与之对应，而每一个具体模版角色都可以给出这些抽象方法（也就是顶级逻辑的组成步骤）的不同实现，从而使得顶级逻辑的实现各不相同。 引用 你把我们的使用hibernateTemplate的方式也叫做模板方法我真的怀疑你对模板的理解。 这个讨论就再也没有意义了，从哪句话可以看出来我说调用模板方法的方式 是反转控制？另外，你不理解spring的模板方法模式，不知道你是否知道有一种引入回调的模板方法模式？ 关于模板方法模式的讨论我将不再继续，修行在个人。 |
| 返回顶楼 | |
|
发表时间：2011-06-01
kakaluyi 写道 redhat 写道 kakaluyi 写道 每个state类持有相同的context的引用， 下面是一个BlueState类，由回调context来实现状态转换（但是状态转换的逻辑封装在context类中，你赞同回调也是控制反转，这边也是回调呀） public class BlueState extends State{ public void handlepush(Context c){ //根据push方法"如果是blue状态的切换到green" ; c.setState(new GreenState()); } public void handlepull(Context c){ //根据pull方法"如果是blue状态的切换到red" ; c.setState(new RedState()); } public abstract void getcolor(){ return (Color.blue)} } 所以我给你指出你的这句话： 引用 状态模式由自己控制状态变化交给了context类 是错的，你把反转的方向搞错了，我给你的回复是：引用 这个是错误的，刚好相反，如果我们使用if-else/switch-case的话，相当于使用了context控制所有的状态变化逻辑和变化后相应的行为，我们使用状态模式，就是把这二者封装给了状态而不是context，请参见漫谈设计模式和GoF设计模式的状态模式章节。 特别是请理解这句话 引用 我们使用状态模式，就是把这二者封装给了状态而不是context 。修行在个人，看造化了。引用 ），状态的互相转化没有反战控制，可能你在这些模式里做了些变化实现了控制反转，但是一般我们不认为是。 这句话是你说的吧，我只是把反转关系写错了，但是你是把整个概念完全理解错了，算了，感觉你自以为是个牛人，我也自以为是个牛人，到底谁是牛人我都觉得不重要 引用 我只是把反转关系写错了 你写错了让人家明白，这个有点wl了，我说过，]我们不认为是状态模式的实现反转控制的原因很清楚了引用 要说反转控制，是不严格的，因为状态之间可以不切换的，所以对于状态的设置也未反转到某些state对象里 看完这些，我只是觉得为什么人家facebook才600人，我们动不动就是4000人，还在说，看：我们的成本多低呀。 关于此方面的讨论，如果没有严谨的证据（不明白的时候往往拍脑袋想出来的是歪理，经不起推敲的），我将忽略不再继续。中国很多技术人员觉得自己是大牛，我不是！请大牛们不拿出证据讨论，我只是明白一些oo思想，做过一些实践，和那些精通oo思想的人无法沟通的，记得有位大牛说自己学习20多年，才有那么懂一点，我更是无可比拟，而这位大牛，用mf的话说就是：是为数不多的能够快速构建模型的人！在他老人家眼里，才有几个大牛？当然，我不是把火引向mf，请查阅mf简介和资历再作评价。 |
| 返回顶楼 | |
|
发表时间：2011-06-03
我的理解简单，就是代码都写好，业务的乱七八糟的东西，都不管，最后你要用什么，配置在容器里，它根据你的配置去调用别的对象，配什么，调什么，没有依赖。
|
| 返回顶楼 | |
|
发表时间：2011-11-09
sunxuetao2010 写道 我的理解简单，就是代码都写好，业务的乱七八糟的东西，都不管，最后你要用什么，配置在容器里，它根据你的配置去调用别的对象，配什么，调什么，没有依赖。
不够深入，还是被其他书籍毒害了呀，把这个概念误读了，请再次看博文或者论坛帖子。 对概念的理解非常重要，打个比方，我们对人的定义是：高级动物，大脑发达。还有人对人的定义是：能够劳动的动物。这些都是正确的，理解的很深刻的，但是有些人偏偏拿出这样的定义忽悠大家：人就是长着两只长耳朵，四条腿子，马形状的，全身灰褐色的，嘴巴是白色的动物。那就是完全被忽悠了！ |
| 返回顶楼 | |
