对于这个简单的OOAD问题,哪个是最优雅的设计？

Question

我试图开始使用OOAD,这个问题出现在我的脑海中,我不确定我能找到一个好的解决方案:(它是现实世界案例的超级隐形版本).

渔夫在有钓鱼竿的一个池塘钓鱼.每次发射钓鱼线时,有可能在有阳光和晚上1/20时捕获等于1/10的鱼.

要定义哪些类？ 我会回答:渔夫,FishingRod,池塘,日(模拟夜晚和白天).

哪种方法？ 我会回答:Fisherman.Launch(FishingRod),FIshingRod.TryToFish(Pond)返回布尔值

如何模拟可能性？谁具有可能性的责任？它不属于渔民或池塘.在这个例子中,只有日光的关系,在现实世界中它可能也与渔夫,钓鱼竿和池塘有关.

如何建模外部因素(日光)？

欢迎任何评论.代码示例.

更新:问题 的第一个评论和tdammers的回答迫使我更具体.正如我上面写的那样"它是现实世界案例的超级隐形版本",无论如何我要说我想要在以后增加复杂性,而不是超级增加它,让我们说增加它就足以让我列出的所有类都很好以上(例如,因为我记录了池塘里有多少鱼,渔民有多累,......).无论如何,对我来说最有趣的问题是"如何模拟可能性"和"外部因素".对于那些在OOAD中没有太多技能的人来说,这是一个新手问题.

Answer 1

我会有渔夫,FishingRod,FishingLine,池塘,鱼和"天空"(或"环境").

在面向对象的土地上,物体通常比你想象的更聪明.渔夫"有一个"(包含)FishingRod.他将FishingLine(FishingRod的一个组成部分)投入Pond.池塘"看"天空以确定它是白天还是晚上,然后滚动骰子以确定它是否应该将鱼放在线上.

抖动的对象层次结构是FishingLine可以选择性地包含Fish,并且由FisherR拥有的FishingRod拥有.Pond包含Fish,接收FishingLines但不"拥有"它们,并且也知道但不拥有Sky.

接下来的方法如下:

Fisherman.FishingRod - 一个初始化属性(或一对getter/setter方法),用于给渔夫一个FishingRod到FishAt()一个池塘.这是可选的; 一个渔夫可以创建他自己的FishingRod,或者他自己可以从FishingRods的集合中选择它,而不是给他的FishingRod.

Fisherman.FishAt(Pond) - 告诉渔夫使用他的FishingRod将钓鱼线发射到池塘,然后检索()它可能会得到一条鱼.

FishingRod.Launch(Pond) - 将FishingRod的FishingLine释放到池塘中.

FishingRod.Retrieve() - 从池塘中取回FishingLine,返回一条鱼,也可能一无所获.

Pond.StockWith(Fish []) - 为渔夫提供池塘鱼以捕获FishingRod.请记住,在OO-land中,一切都必须得到它想要的东西或知道如何制作它; 如果这是你想要遵循的模型,Pond可以很容易地创建Fish,但是这里的用户故事没有说明这是如何发生的(通常意味着它超出了故事的范围).

Pond.SetFishingLine(FishingLine) - 由FishingRod用于将其FishingLine放入池塘.这是包含业务逻辑的"驱动功能".当这个被召唤时,池塘应该询问天空是否有一天,并且可能根据一天中的时间将鱼放在钓鱼线上.

Sky.IsDay() - 一种方法,如果是白天则返回true,如果是黑夜则返回false.

如果你认为池塘不应该直接知道将Fish放在FishingLine上的确切规则,它可以将FishingLine及其Fish []赋予所谓的"纯制造".这个制作"FishingLogic"将是审查天空并应用规则的人.在开发过程中,这通常是一件好事,因为这意味着FishingLogic可以在不改变Pond的情况下进行更改,除非FishingLogic需要更多来自Pond(如水温).

各种对象代表了现实生活中的各种基本"模式":

• 渔夫是一个"演员",与我们的用户最接近.像这样的系统的用户基本上站在演员的肩膀上并告诉他该怎么做.
• FishingRod是"帮手"或"实用程序".它是"工具"的真实模拟,包含状态和业务逻辑的混合,可帮助它执行非常具体的任务.
• 此模型中的FishingLine类似于"请求"或"命令".其唯一目的是从一个物体到另一个物体,当发生这种情况时,它表示接收者应该采取具体行动.
• 鱼是一种"反应"; 请求的答案.可能有一个,也许不是.
• 池塘是一个"存储库"; 它包含东西,并根据一组逻辑处理外部对象对这些东西的请求.
• 天空是一个"国家桶".它具有数据,并通过其接口提供对该数据的访问.
• FishingLogic是一个"纯粹的制造"; 它与我们正在建模的现实世界中的"名词"(对象)没有相似之处,并且存在于包含环境规则,或者在没有模型对象必须知道的情况下发生的事情(鱼如何决定在钩子上？)