朱明磊 (5696**591) 2012-07-24 21:37:25
还有一个问题：由业务用例->业务用例序列图->系统->对每个系统用例->系统用例序列图 的分析过程，自然找到了系统中的对象，然后经过调整后得到较好的设计，这一过程衔接非常自然也很严谨，好像机械动作一样就得到了结果。可是，在这个过程中，好像不需要引入设计模式来辅助规划类与职责的划分，这是否有什么矛盾？
潘加宇 (3504847) 2012-07-24 21:42:15
原理（很少）－－原则（数十）－－模式（上千）
潘加宇 (3504847) 2012-07-24 21:42:53
模式 不等于 "设计模式"，更不等于 "GoF23种设计模式"
潘加宇 (3504847) 2012-07-24 21:44:20
想学习"GoF设计模式"，套用到设计上就能解决设计问题，这是不了解情况
潘加宇 (3504847) 2012-07-24 21:45:02
确实要用到模式，包括该领域的前人总结的分析模式，以及所使用平台推荐的架构模式
朱明磊 (5696**591) 2012-07-24 21:48:12
是否设计模式更适合用到"支撑系统"中（如权限，orm等领域），而在业务系统中不是太重要
潘加宇 (3504847) 2012-07-24 21:48:16
但多半不是GoF哪些模式，哪些模式之所以出名，并非最有用，并非最本质，而是最早写在书上，并把书起名为"设计模式"而已。
就像象棋的残局定式一样，想通过背诵几个最古老的书上的定式赢棋，那是开玩笑了
潘加宇 (3504847) 2012-07-24 21:49:00
先要想清楚自己说的"设计模式"是什么意思。
剪刀手爱德华 (4617***67) 2012-07-24 21:49:38
哇，老师说的好透彻啊
朱明磊 (5696**591) 2012-07-24 21:49:46
就是刚才你说的"古老"的定式（gof等）
剪刀手爱德华 (4617***67) 2012-07-24 21:50:41
呵呵 UML设计也不止包括Gof啊
朱明磊 (5696**591) 2012-07-24 21:50:48
按老师的说法，类，职责划分是自然的分解，不需要很多定式就得到了，这个让我印象非常深刻
剪刀手爱德华 (4617***67) 2012-07-24 21:51:58
什么叫自然的分解啊
朱明磊 (5696**591) 2012-07-24 21:52:05
类和职责的规划，就像组织中人的职责的划分，好像非常一致，这种理解有误吗？
朱明磊 (5696**591) 2012-07-24 21:53:39
自然的分解：我是指，业务建模到系统建模过度非常自然：由业务用例->业务用例序列图->系统->对每个系统用例->系统用例序列图 的分析过程，自然找到了系统中的对象，然后经过调整后得到较好的设计，这一过程衔接非常自然也很严谨，好像机械动作一样就得到了结果
剪刀手爱德华 (4617***67) 2012-07-24 21:54:27
可是这些跟具体类的设计有什么关系呢
剪刀手爱德华 (4617***67) 2012-07-24 21:55:05
每个用例你打算用多少个类呢？
朱明磊 (5696**591) 2012-07-24 21:55:45
按照这个套路，类和职责都是自动出来的啊。
潘加宇 (3504847) 2012-07-24 21:56:13
"机械动作"不会的，要基于对领域的理解，理解得越深，越接近最佳答案
剪刀手爱德华 (4617***67) 2012-07-24 21:56:32
呵呵 如果都能自动出来 就用不着设计模式了啊
剪刀手爱德华 (4617***67) 2012-07-24 21:57:00
单例模式 装饰模式 职责链模式 这些都能自动生成吗
潘加宇 (3504847) 2012-07-24 21:57:07
"类和职责都是自动出来的啊。"不动脑子出来的多半是没价值的
朱明磊 (5696**591) 2012-07-24 21:57:32
不是真指"机械"，是说几个套路下来，就基本出来了，感觉听神奇的
剪刀手爱德华 (4617***67) 2012-07-24 21:57:50
貌似目前好像没有这种工具吧
呵呵
朱明磊 (5696**591) 2012-07-24 21:58:09
然后加上头脑来调整就行了
潘加宇 (3504847) 2012-07-24 21:58:28
模式开了那么多年的会，出了那么多卷书，不要再去玩那些没用的GoF"单例模式 装饰模式 职责链模式"了
剪刀手爱德华 (4617***67) 2012-07-24 21:58:57
呵呵 我是提出对他的想法的一些疑问
剪刀手爱德华 (4617***67) 2012-07-24 21:59:05
不过自己也没掌握多少
剪刀手爱德华 (4617***67) 2012-07-24 21:59:25
老师有时间还是要在群里多指点一下
潘加宇 (3504847) 2012-07-24 22:01:31

潘加宇 (3504847) 2012-07-24 22:02:34
如果是有1-1固定规律的，归纳成套路，由计算机映射或者培训人工机械映射
把脑力花在多对多的地方
朱明磊 (5696**591) 2012-07-24 22:02:38
领域模型中的类是带了很多方法的类，不是贫血模型中的类，可是这种类在分布式通讯中无法跨越系统边界，处理这种情况的最佳实践有吗？
潘加宇 (3504847) 2012-07-24 22:03:32
看所使用平台推荐的架构模式
朱明磊 (5696**591) 2012-07-24 22:17:45
还有一点感悟，看看是否理解的对：大部分gof模式是为了应对变化而做的套路，避免小的变化引起代码地震，最终还是解耦的问题。而领域建模，本身认为业务内核相对是很稳定的，因此找到最本源的业务协同体系，映射成应用模型，本身就会稳定，而业务内核之外通过边界类隔离，可以隔离适配外部的变化。
朱明磊 (5696**591) 2012-07-24 22:20:09
业务内核相对稳定，和是否使用计算机系统关系不大，计算机系统如果正确模拟了业务系统，就能以不变应对变化。
沉睡的大熊 (2584**852) 2012-07-25 00:09:00
相对而言，业务是最容易变化的