咖啡机的启示.pptVIP

为什么要创建一个受保护的startBrewing()方法呢? 为什么不在M4UserInterface中直接调用start()函数呢？ IsReady()测试以及随后对HotWaterSource和ContainmentVessel的start()方法的调用都是高层的策略，都应该属于UserInterface类。 无论我们是不是实现Mark IV，这段代码都是有效的，因此不应该和对应于Mark IV的派生类耦合在一起。这是另外一个单一职责原则（SRP）的实例。 在本例中，我们将尽可能多地把代码放在高层类中。我们只把那些必须得和Mark IV关联在一起的代码放到派生类中。 实现IsReady()方法 如何实现HotWaterSource和ContainmentVessel的IsReady()方法呢？ 它们都是抽象方法，因此这两个类也都是抽象类。 相应的两个派生类M4HotWaterSource和M4ContainmentVessel会通过调用合适的CoffeeMakerAPI函数进行实现。 实现Start()方法 HotWaterSource的Start()方法只是一个抽象函数， M4HotWaterSource会实现该方法去调用CoffeeMakerAPI中关闭阀门以及开启加热器的函数。 ContainmentVessel的Start()方法略有不同。M4ContainmentVessel只要做一件事情：记住系统的工作状态。以后，当把咖啡壶放到保温盘或者从保温盘上取下咖啡壶时，这个状态会使系统做出正确反应。 系统如何检测传感器状态 系统的控制流是如何运转到调用CoffeeMakerAPI.GetBrewButtonStatus()函数的地方的呢？ 系统的控制流是如何运转到可以检测任何传感器的地方的呢？ 多线程？ 轮询？ 假设系统运行在一个不支持线程的小平台上的情况，这意味着我们必须采用轮询。 那该如何做呢？ 定义一个Pollable接口，该接口只有一个Poll()方法。 如果M4UserInterface实现了这个接口，且Main()程序就待在一个循环中，不停一遍一遍地调用这个方法会如何呢？ 控制流就会不断地进入M4UserInterface，我们就可以检测冲煮按钮了。 我们把这种模式应用到M4的全部三个派生类中。每一个都有自己需要检测的传感器。因此，我们可以让所有M4的派生类都继承Pollable，并在Main()中调用它们，实现轮询。 五、这个设计的优点 尽管问题本身非常简单，但是这个设计仍然展示了一些非常好的特征。 用线条把其中的3个抽象类圈起来。这些类涵盖了咖啡机系统的高层策略。 注意，和该线条交叉的所有依赖关系都是指向圈内的。圈中的类没有依赖于任何圈外的类。因此，抽象完全和细节隔离开了。 这3个抽象基类可以在许多不同种类的咖啡机中重用。 这种高层策略和细节的隔离正是OOD的本质所在。 当设计者创建出没有方法的图示时，他们也许不是根据行为对软件进行划分的。不基于行为的划分基本上都是严重错误的。 * 2.3 虚构的抽象 Sensor和Heater 很多抽象是不适合编程基类的。尤其在这个设计中，根本不需要任何基类。 原则：谁使用它们？ 系统中所有的类都没有使用Sensor类和Heater类。 如果没有任何类使用它们，它们还有存在的必要吗？ 有时，如果基类能够为子类提供一些公共的代码，我们也许还能容忍其没有任何使用者。但是这两个基类不具有任何代码，最多具有一些抽象的方法。 Public interface Heater { void TurnOn(); void TurnOff(); } Sersor类更加糟糕！ 和Heater类一样，它只有抽象方法并且没有使用者。 更糟糕的是它仅有的方法的返回值是不明确的。BoilerSensor是两态的，而WarmerPlateSensor确实三态的。简而言之，我们无法再接口中指明Sensor的契约。只能说传感器回返回一个int值。 Public interface Sensor { int Sense(); } 2.4 上帝类 上帝类——把系统中所有智能都集中在单独一个对象或者函数上。 OOD的目标之一就是要把系统的行为进行划分并分布到多个类和函数上。 然而，有很多看起来进行了行为分布的对象模型，其实含有大量带有伪装的上帝类。 CoffeeMaker类 三、改进方案 咖啡机问题是一个有趣的抽象练习。 解决这个问题的技巧：退一步海阔天空。 把问题的本质和其细节分离。忘掉加热器、阀门、传感器等所有的小细节，集中关注于根本的问题。 3.1 关注本质 根本问题：如何煮咖啡？ 最简单、最常见的方法是把热水倒在研磨好的咖啡上，并把冲泡好的咖啡液体收集在某种器皿中。 热水从哪里来？ H