走单骑(376***455) 17:16:19
电饭煲对象能自己做饭么？
走单骑(376***455) 17:20:46
如果说人作为对象能做饭，大家都认同。
奋斗(224***36) 17:21:47
锅是一个做饭的工具 人调用锅的做饭的接口 并传递参数 然后锅输出饭
走单骑(376***455) 17:23:05
要做饭就定义个"做饭接口"？
肘子(23***95) 17:23:19
把锅作为参数传递给人，然后调用人做饭的方法也可以做饭吧
走单骑(376***455) 17:23:51
传来传去，还是"做饭接口"
奋斗(224***36) 17:24:08
那你那是人的职责呢还是锅的职责呢？
奋斗(224***36) 17:24:25
做饭是人的功能还是锅的功能？
走单骑(376***455) 17:24:55
人和锅都可以用"做饭接口"
奋斗(224***36) 17:25:10
如果人是个厨师， 你能给他一个锅的参数，让他用指定的锅做饭
Ynot(41***25) 17:25:19
做饭是人的功能. 也可以是锅的功能.
奋斗(224***36) 17:25:32
具体场景具体分析罢了
肘子(23***95) 17:37:48
电饭煲肯定有做饭接口吧
走单骑(376***455) 17:38:55
接口是：放米-加电-成饭
owen(25***80) 17:39:10
煲汤，煮粥，煮饭
owen(25***80) 17:39:44
对外提供三个接口，煲汤，煮粥，煮饭
owen(25***80) 17:40:15
放米又不是电饭锅做的
走单骑(376***455) 17:40:27
煲汤，煮粥，煮饭好像功能的分解
肘子(23***95) 17:40:58
放米，加电不是电饭煲的责任吧
owen(25***80) 17:41:10
嗯，不是
奋斗(224***36) 17:41:15
如果拿锅做边界的话，你的做饭这个用例粒度太大了
奋斗(224***36) 17:41:46
你的锅可以烧水，煲粥，炒菜。。
owen(25***80) 17:41:57
这个是电饭锅
奋斗(224***36) 17:41:57
这样的粒度可以
奋斗(224***36) 17:42:38
锅是研究对象还是人是研究对象呢
走单骑(376***455) 17:43:04
锅是研究对象
奋斗(224***36) 17:43:39
那就先分析这个锅能用来做什么吧
走单骑(376***455) 17:43:55
怎么分析？
走单骑(376***455) 17:45:49
煲汤流程+煮粥流程+煮饭流程
走单骑(376***455) 17:46:18
还不如煲汤接口+煮粥接口+煮饭接口
落夜(643***31) 11:36:50
就这个饭和米的问题我都觉得有太多问题了，对人来说越快煮好煮好吃很重要，对市场来说，功能越多越好，能占领市场，而老师说了，需求就是为改进业务上的问题，让产品变得有竞争力！那么问题来了？业务目标是什么？谁是这业务的决策者！来个系统一点的建模吧！
潘加宇(3504847) 17:23:36
@走单骑(376***455) 17:38:55
接口是：放米-加电-成饭
@owen(25***80) 17:39:44
对外提供三个接口，煲汤，煮粥，煮饭
--这些都是一样的问题，看起来有类甚至有接口，很高大上，但只不过不是功能分解加了一层类的皮，和之前说的er，or类一样的，类图长得像用例图，没有得到面向对象的的好处
--真正面向对象的思考方式是：电饭锅要能做饭，需要懂得什么，可能需要懂得：食材，食材类型（米、肉、薯）、各种食材类型适用的烹调规格（煮粥，煮饭，煮汤。。。），热源类型，热源规格，容器类型，容器规格……主要逻辑应该封装在这些核心的实体类中，由这些实体类协作来实现用例，"接口"只是用于表达和执行者交互的边界，例如"热源接口"，"厨师接口"。
--注意，上面抽象用词是热源、食材、容器，没有电，没有饭，也没有锅。也就是说，设计要源于需求，高于需求，才能随着需求的变化保持稳定。
--当然，以上说法是电饭锅比较智能的情况下。现在的电饭锅并没有那么智能（所以便宜），所有信息都是由外面的执行者指定的。电饭锅只需要记住人指定的设置，执行就可以。你在锅里放一块骨头，然后要求煮粥，它也照样执行。没多少逻辑的系统，面不面向对象区别不是很大。
走单骑(376***455) 17:38:25
嗯，热源、食材、容器等，做为实体类可以。
UML菜鸟(12***22) 20:52:29
按上面说电饭锅要能做饭，抽象用词是热源、食材、容器，没有电，没有饭，也没有锅。
那人与人之间发生交易。比如买股票。那是不是不应该有证券交易所，而是应该有，投资人，融资企业，债权债务关系。