《面向对象设计实践指南》读书笔记
编辑:lin13459411179 成考报名 发布时间：09-26 阅读：
《面向对象设计实践指南》读书笔记
面向对象应用由类组成，但是由消息定义，类控制着源代码的内容(静态)，而消息体现的是活生生的应用(动态)。
设计必须关心对象之间传递的消息。它不仅要解决对象所知道的内容(职责)，以及对象都知道谁(依赖谁)的问题，还要解决他们彼此间如何进行对话的问题(消息接口)。
类的接口暴露的过多，相互参杂，会导致这些对象被精细地、明确地和容灾性的调整到只能做他们现在所做的事情。
每一个类都尽可能少的暴露自己，并且尽可能少的知道其它对象，可以让这个类变成可插拔的组件，增加其灵活性。
每个类就像一个厨房。类的存在除了要实现许多方法，还要满足单一职责。公共部分和私有部分之间的存在差别，且是最有效的做事方法。如果让顾客来知道烹饪，那么当厨房配料不足，以及需要更换人手时，他们就不得不在接受培训。使用菜单避免了这个问题，让每一位顾客只询问他们想要的东西，同时不用知道有关厨房是如何制作它的任何事情。
公共接口
暴露了其主要职责
期望被其它对象调用
不会因一时兴起而改变
对其他依赖它的对象来说是安全的
在测试里被详尽的记录
私有接口
要处理实现细节
不希望被发送到其它对象
可以因任何不明的原因而变化
对其他依赖它的对象来说不安全
可能在测试里被引用
类的公共部分是稳定的，而私有部分则是多边的。当将方法标识为公共或私有时，你便在告诉这个类的用户： 哪些方法是可以安全依赖的。当你的类使用了其他类的公共方法时，你就选择了相信这些方法是稳定的。当你决定依赖于其他对象的私有方法时，你应该明白：你正依赖某些天生就不够稳定的事物，因此它会增加你的风险，让你受到某个遥远毫不相干的变化所产生的影响。
有着丰富设计经验的设计师，他们在心里建立了一张地图，其中描绘的是这个应用程序里可能存在的各种对象，以及他们之间可能存在的交互。他们不会束缚于任何特定的想法，并且会计划使用测试来发现替代品。
领域对象(需求中那些浅显的名词)会被很容易找出来，但它们不是程序的设计中心。事实上，他们是一个为粗心大意而设立的陷阱。如果你关注这些领域对象，你就会倾向于给它们强加上行为。设计专家们也会注意到这些领域对象，但不会把精力放置到它们身上。他们不会去关注这些对象;相反，他们会去关注它们之间传递的消息。这些消息会引导你去发现其他的对象，而这些对象可远没有那么明显。
时序图
时序图提供了一种简单的方式，用来对不同对象的排列和消息传递方法进行试验。
时序图两个主要部分: 对象和它们之间传递的消息
横线表示的是消息。当有消息发送时，横线会被贴上消息的名称。消息的结尾或开始带有一个箭头，箭头指向接受者。当某个对象忙于处理接收到的消息时，它会变成活跃的，并且其数显会扩大成为一个垂直的矩形。
上图被解读为： 顾客Moe现将suitable_traips消息发送到Trip类;接着，这个类会被激活，并处理这条消息;在处理完成之后，这个类会返回一个响应。
用例里的名词在时序图里变成了对象，而用例的动作都变成了消息。
时序图的价值在于： 它们明确指定了对象间传递的消息，因为对象间只应该使用公共接口进行通信;时序图是一种用于暴露、试验并最终定义这些接口的工具。
面向消息的设计，首先要确定发送弄些消息，其次是这些消息要被发送到哪里?
从基于类的设计转变为基于消息的设计，这是你设计生涯中的一个转折点。从基于消息的角度比从基于类的角度更能产生出灵活的应用程序。将那个基本设计问题从『我知道我需要这个类，那该怎么办?』转变为『我需要发送这条消息，谁应该响应它呢?』
『你发送的消息不是因为你有了对象，你有了对象是因为你要发送消息』
醍醐灌顶，有没有
请询问『要什么』，别告知『如何做』
寻求上下文独立
对象所期望的上下文会直接影响到重用它的难度。具有简单上下文的对象易于使用，也易于测试，他们对周边的环境期望很少。具有复杂上下文的对象难以使用，也难以测试，在它们能够做任何事情之前，都需要进行复杂的设置
最好的情况是对象与它们的上下文保持完全独立。如果某个对象在与其他堆叠进行合作时，不知道他们是谁，也不知道它们所做的事情，那么这个对象便可以按各种千奇百怪和完全无法预测的方式重用，依赖注入就是一个可以帮助剥离上下文的技术。
创建基于消息的程序
使用时序图来探究设计，定义公共接口，以及发现对象。时序图可以用来做瞬态分析，可以帮助理解过程，有助于我们将焦点集中在消息上，并让我们形成一个合理的意图目的，将注意力从对象转换到消息，可以让我们专注设计一个建立在公共接口上的应用程序。