1,268
社区成员
发帖
与我相关
我的任务
分享作一个简单的调查。
一个简单的场景：客户到了，选择了商品，付款后离开。
请大家使用面向对象的方法，简单回答，你会找到什么类，类中会有什么方法，什么属性。简单回答就可以，我明白意思就可以了。
请大家使用面向对象的方法，简单回答，你会找到什么类，类中会有什么方法，什么属性。简单回答就可以，我明白意思就可以了。
...全文
请发表友善的回复…
发表回复
chenszhs 2004-01-04
- 打赏
- 举报
ozzzzzz (希望敏捷) ：
哈哈，这叫场景吗？
目标、环境都没有
用例：
客户－买商品
全部ok
哈哈，这叫场景吗？
目标、环境都没有
用例：
客户－买商品
全部ok
i_jianyong 2003-12-29
- 打赏
- 举报
customer, product, cashier, order, payment
mach 2003-12-29
- 打赏
- 举报
呵呵，大家的答案非常有趣，尤其是gigix的
从ozzzzzz的场景看不出任何意图，在这种情况下，唯一要做的不过是描述这个领域模型罢了，这很简单，场景中可以有以下对象：
顾客
商品
Cashier
它们之间的关系一目了然，我就不费劲陈述了
建模的目的在于使原本复杂的关系更加清晰明了而不是更加复杂难懂，可惜的是我看到很多人所做的却是恰恰相反。
在这个场景中使用设计模式就更加有意思了，所谓设计模式，其中的“设计”很重要，而在这个看不出意图的场景中，在并不清楚要“设计”什么的请卡，引用什么设计模式根本没必要。
这个场景很简单，所以它的模型也很简单，用领域的词汇/语言描述它就足够了。
从ozzzzzz的场景看不出任何意图，在这种情况下，唯一要做的不过是描述这个领域模型罢了，这很简单，场景中可以有以下对象：
顾客
商品
Cashier
它们之间的关系一目了然，我就不费劲陈述了
建模的目的在于使原本复杂的关系更加清晰明了而不是更加复杂难懂，可惜的是我看到很多人所做的却是恰恰相反。
在这个场景中使用设计模式就更加有意思了，所谓设计模式，其中的“设计”很重要，而在这个看不出意图的场景中，在并不清楚要“设计”什么的请卡，引用什么设计模式根本没必要。
这个场景很简单，所以它的模型也很简单，用领域的词汇/语言描述它就足够了。
leeseon 2003-12-28
- 打赏
- 举报
正好最近在看Role Object、Role Model与AOP的论文，楼主的想法很有意思；gigix的对我很有启发，不过刚看，不敢随便发表评论:(
不过如果算是调查，我的寻找类的方法也是名词法来着，聊作答卷吧。
不过如果算是调查，我的寻找类的方法也是名词法来着，聊作答卷吧。
showerXP 2003-12-27
- 打赏
- 举报
题目：客户到了，选择了商品，付款后离开
回答：
就上面简单的一句话回答，而不扩展了。
实体类：客户，商品
边界类：柜台，收银台
控制类：购物付款规则……
回答：
就上面简单的一句话回答，而不扩展了。
实体类：客户，商品
边界类：柜台，收银台
控制类：购物付款规则……
ozzzzzz 2003-12-26
- 打赏
- 举报
Panr(光荣)
你小子是不是又要让我去看你的帖子了，看来上次骂你骂的还不够：）
玩笑开了，说点正经的了。我不认为AOP总是要附属于OO，它应该有自己的特有的生存空间。而我认为AOP的发展根本还在于能否找到它的一条分析问题的途径，然后就是找到一个使它能够更有效的工具，最后就是形成一下模式性的解决问题的方案。
AOP分析问题的方法可以说是它能否独立存在的基石，如果找不到一个分析问题发现ASPECT的途径，那么AOP就不会有什么大发展，而永远是一个寄生者。
你小子是不是又要让我去看你的帖子了，看来上次骂你骂的还不够：）
玩笑开了，说点正经的了。我不认为AOP总是要附属于OO，它应该有自己的特有的生存空间。而我认为AOP的发展根本还在于能否找到它的一条分析问题的途径，然后就是找到一个使它能够更有效的工具，最后就是形成一下模式性的解决问题的方案。
AOP分析问题的方法可以说是它能否独立存在的基石，如果找不到一个分析问题发现ASPECT的途径，那么AOP就不会有什么大发展，而永远是一个寄生者。
Panr 2003-12-26
- 打赏
- 举报
噢，除了增加兴趣还可以降低交流成本，这还是不会促进学科技术的进步
Panr 2003-12-26
- 打赏
- 举报
Aspect只是划分软件模块的线索，而“面对对象”是软件的一种模块而已
提倡“面对对象”的设计只是“用方块字代替冗长的英文单词”；AOP则是透过语言的边界研究“数学建模”
“推广方块字”顶多增加参与者的兴趣而已，并不会促进学科技术的进步
提倡“面对对象”的设计只是“用方块字代替冗长的英文单词”；AOP则是透过语言的边界研究“数学建模”
“推广方块字”顶多增加参与者的兴趣而已，并不会促进学科技术的进步
Panr 2003-12-26
- 打赏
- 举报
被预测为“可能发生变化”的那些需求被称为concern，一个软件过程必然有零个或若干个concern
一般把某个业务性的concern 作为划分软件模块的线索，这个线索就是Aspect
除了Aspect以外的其它concern，都被称为“横切关注点”
“横切关注点”的被集成到Aspect 的过程将被格外关注和设计，这样就应付可能的需求变化
如果“横切性的需求变化”被及早地发觉，被作为“横切关注点”良好地安排对待了，那么软件过程将是稳定的；否则就是增加了风险
-----
ＯＯ首先是分析方法。而ＡＯＰ只是设计的策略，决对不是分析方法！
就像顶楼你会问大家会“找到什么类”，所以你永远无法“得出AOP会代替OO”的结论
其实你可以发现我前面《细说信息流转》的帖子就是从“区分需求变化是否具有横切性”做为讨论的最初起点的
一般把某个业务性的concern 作为划分软件模块的线索，这个线索就是Aspect
除了Aspect以外的其它concern，都被称为“横切关注点”
“横切关注点”的被集成到Aspect 的过程将被格外关注和设计，这样就应付可能的需求变化
如果“横切性的需求变化”被及早地发觉，被作为“横切关注点”良好地安排对待了，那么软件过程将是稳定的；否则就是增加了风险
-----
ＯＯ首先是分析方法。而ＡＯＰ只是设计的策略，决对不是分析方法！
就像顶楼你会问大家会“找到什么类”，所以你永远无法“得出AOP会代替OO”的结论
其实你可以发现我前面《细说信息流转》的帖子就是从“区分需求变化是否具有横切性”做为讨论的最初起点的
scalene 2003-12-26
- 打赏
- 举报
BirdGu(鲲鹏) ：你说的很对。不过我想描述的是一种偷懒的思考方式来解决前面ozzzzzz(希望敏捷)所说的“名词”和“动词”的问题。因为如你所说，名词可以动词化，动词也可以名词化，当你考虑不清应该选择什么做名词，什么做动词的时候，考虑什么需要持久化可能这个问题就迎刃而解了。不是什么上得了台面的方式，不过我觉得很有效。
Panr 2003-12-26
- 打赏
- 举报
ozzzzzz(希望敏捷):
只要骂的有理，被骂也痛快，我就喜欢被骂，哈哈哈～
-----
／／选取功能关注点为模块划分的Aspect
见上
／／选取性能关注点为模块划分的Aspect
／／ 通过备选商品的策略影响“闲逛实例”的分布
／／ 通过商品目录的策略影响“购物实例”的分布
／／ 通过收银员的策略影响“交易实例”的分布
备选商品
商品目录（备选商品的列表）
收银员
闲逛（有顾客、商店、时间等属性）
购物（从闲逛类继承。多了ObjectIsOrdered状态的商品的列表）
交易（聚合一个选择类的实例，主要是清算交割等方法）
／／选取可靠性关注点为模块划分的Aspect
／／ 列出法人实体如：商家、顾客、收银员
／／ 强调凭据的法律效力如：订购单、帐单
商家
顾客
收银员
备选商品
订购单
帐单
讨论
模块划分的标准应该唯一，所以只有一个关注点会被提升成为aspect，其它的都会沦成cross cutting
一个航空售票系统将商品目录放在多个WebServer上，要增加自动WebServer定位的功能，而飞机票对象则全局唯一
这属于性能关注点的作用，如果原来的系统是使用“功能关注点”为Aspect的软件自动机器，那这就成了无奈的鸡肋
-----
现阶段的面对对象程序只不过基于对象而已，是面对对象的人和基于对象的程序（人在什么时候不‘面对对象’过么？？？）
只有程序自身具有概念的演化能力以后才能真正称为面对对象程序
那么什么是基于对象呢？抽象数据类型只是软件的一种模块，除了抽象数据类型，我们还可以用包，用文件，用名字空间...
也许基于对象的模块单位可以以最少的字节数达到同样的交流的效果，充其量也不过是语言中的方块字，我们当然可以说它的交流效果好，而方块字仅仅只能是语言，不会成为交流的法门
就软件设计本身而言
现在的面对对象只是模块的单位而已，用其它模块单位来构造软件也是一样的
无论我用五笔还是智能ABC，这并不能增进我的数学建模的水平，数学建模就是软件设计
只要骂的有理，被骂也痛快，我就喜欢被骂，哈哈哈～
-----
／／选取功能关注点为模块划分的Aspect
见上
／／选取性能关注点为模块划分的Aspect
／／ 通过备选商品的策略影响“闲逛实例”的分布
／／ 通过商品目录的策略影响“购物实例”的分布
／／ 通过收银员的策略影响“交易实例”的分布
备选商品
商品目录（备选商品的列表）
收银员
闲逛（有顾客、商店、时间等属性）
购物（从闲逛类继承。多了ObjectIsOrdered状态的商品的列表）
交易（聚合一个选择类的实例，主要是清算交割等方法）
／／选取可靠性关注点为模块划分的Aspect
／／ 列出法人实体如：商家、顾客、收银员
／／ 强调凭据的法律效力如：订购单、帐单
商家
顾客
收银员
备选商品
订购单
帐单
讨论
模块划分的标准应该唯一，所以只有一个关注点会被提升成为aspect，其它的都会沦成cross cutting
一个航空售票系统将商品目录放在多个WebServer上，要增加自动WebServer定位的功能，而飞机票对象则全局唯一
这属于性能关注点的作用，如果原来的系统是使用“功能关注点”为Aspect的软件自动机器，那这就成了无奈的鸡肋
-----
现阶段的面对对象程序只不过基于对象而已，是面对对象的人和基于对象的程序（人在什么时候不‘面对对象’过么？？？）
只有程序自身具有概念的演化能力以后才能真正称为面对对象程序
那么什么是基于对象呢？抽象数据类型只是软件的一种模块，除了抽象数据类型，我们还可以用包，用文件，用名字空间...
也许基于对象的模块单位可以以最少的字节数达到同样的交流的效果，充其量也不过是语言中的方块字，我们当然可以说它的交流效果好，而方块字仅仅只能是语言，不会成为交流的法门
就软件设计本身而言
现在的面对对象只是模块的单位而已，用其它模块单位来构造软件也是一样的
无论我用五笔还是智能ABC，这并不能增进我的数学建模的水平，数学建模就是软件设计
BirdGu 2003-12-26
- 打赏
- 举报
scalene(南瓜汤)
如果是在分析阶段的话，似乎不应该考虑“数据如何持久化”这样的实现相关的因素吧？
诚然，你所说的那几个系统中的分析模式确实是不同的，但这种不同不是由于“数据如何持久化”的差别而引起的，而是由于在这几个系统中所关心的范围是不一样的。比如在POS机中就不会有客户类（对客户的信息不关心），恐怕也不需要关心库存和财务。而如果是小商店的管理系统，同样不会有客户类，库存和财务恐怕就需要考虑在内了。
如果是在分析阶段的话，似乎不应该考虑“数据如何持久化”这样的实现相关的因素吧？
诚然，你所说的那几个系统中的分析模式确实是不同的，但这种不同不是由于“数据如何持久化”的差别而引起的，而是由于在这几个系统中所关心的范围是不一样的。比如在POS机中就不会有客户类（对客户的信息不关心），恐怕也不需要关心库存和财务。而如果是小商店的管理系统，同样不会有客户类，库存和财务恐怕就需要考虑在内了。
linpeiwen 2003-12-26
- 打赏
- 举报
sign，有空再细看
scalene 2003-12-26
- 打赏
- 举报
ozzzzzz(希望敏捷)：
不同情景下的分析方式可能不同。对于这个case，数据如何持久化可能是影响划分类的方式的关键因素。比如考虑以下情景，POS机（定时和主机同步数据），小商店里直接连接数据库的小系统，个人理财系统，RPG游戏，他们都会有你描述的场景，但是得到的分析结果应该是不同的。也许我是一种数据为中心的思考方式。
不同情景下的分析方式可能不同。对于这个case，数据如何持久化可能是影响划分类的方式的关键因素。比如考虑以下情景，POS机（定时和主机同步数据），小商店里直接连接数据库的小系统，个人理财系统，RPG游戏，他们都会有你描述的场景，但是得到的分析结果应该是不同的。也许我是一种数据为中心的思考方式。
zxl_l 2003-12-26
- 打赏
- 举报
ozzzzzz(希望敏捷)
方案一客户类不一定会有一个方法买东西,若客户类信息只是为了在付款类中属性调用，就没有方法买东西，而是新增等方法，场景必须与系统管理的业务功能需求相结合进行检索类、类中会有什么方法及什么属性等信息。名词法还是动词法等都是提供一种分析类、类中会有什么方法及什么属性等的途径，在实际项目中很少只使用一种方法就能分析出所有的类、类中会有什么方法及什么属性等。
方案一客户类不一定会有一个方法买东西,若客户类信息只是为了在付款类中属性调用，就没有方法买东西，而是新增等方法，场景必须与系统管理的业务功能需求相结合进行检索类、类中会有什么方法及什么属性等信息。名词法还是动词法等都是提供一种分析类、类中会有什么方法及什么属性等的途径，在实际项目中很少只使用一种方法就能分析出所有的类、类中会有什么方法及什么属性等。
stephenli 2003-12-26
- 打赏
- 举报
主要是商品类、帐单类，
属性是细化的东西，要看你的需要了
属性是细化的东西，要看你的需要了
zxl_l 2003-12-26
- 打赏
- 举报
实践是检验真理的标准，AOP及OO的发展依赖于项目分析中的使用。
prosadn 2003-12-26
- 打赏
- 举报
关注ozzzzzz(希望敏捷)的调查结果。
又能好戏看了。
这次一定又学到不少。
~!~
又能好戏看了。
这次一定又学到不少。
~!~
zxl_l 2003-12-26
- 打赏
- 举报
AOP和OO是相对独立的，就如SQL与ORACLE，你能说SQL附属于ORACLE的？
libi 2003-12-26
- 打赏
- 举报
仔细看了各位的帖子，发现我的第一份答卷没押题，现在再补一份。
不管是用名词法还是动词法，我们的目的是为了获得稳定的、高内聚、低耦合的模块。在那篇讨论权限的帖子里，我提了个把“当班人员可以查询业务记录”改为“人员可以在当班时查询业务记录”说法，这是一种设计技巧，或者说是不同的理解方式，区别就在于“当班”是与主语耦合还是与谓语耦合，这就需要看问题具体情况而定。
回到名词法和动词法的问题，我觉得还是要看具体情况，有些问题也许用名词法比较合适，有些则也许用动词法合适（至少我觉得工作流用动词法比较合适）。所以我的态度，不管名词动词，有助于解决问题的，就拿来用，最好是一个问题里可以名词法和动词法同时共存。
如果要把名词法和动词法单独拿来说，名词法有个先天的优势－－容易识别，而动词法有个先天的弱点——离不开名词，就好像楼主提出的“买东西”，“买”单独是难以成为对象的，它必须与“东西”配对，虽然目前“东西”还不明确。这也是为什么我们大多数权限系统只用power而不用privilege的原因，要从动宾词组中解耦出动词和宾语是困难的。
诚如楼主所言，动词法要想解决问题，要先有自己的一套分析方法。这个我就不懂了，密切关注中。
不管是用名词法还是动词法，我们的目的是为了获得稳定的、高内聚、低耦合的模块。在那篇讨论权限的帖子里，我提了个把“当班人员可以查询业务记录”改为“人员可以在当班时查询业务记录”说法，这是一种设计技巧，或者说是不同的理解方式，区别就在于“当班”是与主语耦合还是与谓语耦合，这就需要看问题具体情况而定。
回到名词法和动词法的问题，我觉得还是要看具体情况，有些问题也许用名词法比较合适，有些则也许用动词法合适（至少我觉得工作流用动词法比较合适）。所以我的态度，不管名词动词，有助于解决问题的，就拿来用，最好是一个问题里可以名词法和动词法同时共存。
如果要把名词法和动词法单独拿来说，名词法有个先天的优势－－容易识别，而动词法有个先天的弱点——离不开名词，就好像楼主提出的“买东西”，“买”单独是难以成为对象的，它必须与“东西”配对，虽然目前“东西”还不明确。这也是为什么我们大多数权限系统只用power而不用privilege的原因，要从动宾词组中解耦出动词和宾语是困难的。
诚如楼主所言，动词法要想解决问题，要先有自己的一套分析方法。这个我就不懂了，密切关注中。
加载更多回复（55）
