[转载]-如何向妻子解释OOD

翻译原文：http://www.cnblogs.com/niyw/archive/2011/01/25/1940603.html

此文译自CodeProject上<How I explained OOD to my wife>一文，该文章在Top Articles上排名第3，读了之后觉得非常好，就翻译出来，供不想读英文的同学参考学习。

作者(Shubho)的妻子(Farhana)打算重新做一名软件工程师(她本来是，后来因为他们孩子出生放弃了)，于是作者就试图根据自己在软件开发设计方面的经验帮助她学习面向对象设计(OOD)。

自作者从事软件开发开始，作者常常注意到不管技术问题看起来多复杂，如果从现实生活的角度解释并以对答的方式讨论，那么它将变得更简单。现在他们把在OOD方面有些富有成效的对话分享出来，你可能会发现那是一种学习OOD很有意思的方式。

下面就是他们的对话：

Shubho:亲爱的，让我们开始学习OOD吧。你了解面向对象原则吗？

Farhana:你是说封装，继承，多态对吗？我知道的。

Shubho:好，我希望你已了解如何使用类和对象。今天我们学习OOD。

Farhana:等一下。面向对象原则对面向对象编程(OOP)来说不够吗？我的意思是我会定义类，并封装属性和方法。我也能根据类的关系定义它们之间的层次。如果是，那么还有什么？

Shubho:问得好。面向对象原则和OOD实际上是两个不同的方面。让我给你举个实际生活中的例子帮你弄明白。

再你小时候你首先学会字母表，对吗？

Farhana:嗯

Shubho:好。你也学了单词，并学会如何根据字母表造词。后来你学会了一些造句的语法。例如时态，介词，连词和其他一些让你能造出语法正确的句子。例如：

"I" (代词) "want" (动词) "to" (介词) "learn" (动词) "OOD"(名词)。

看，你按照某些规则组合了单词，并且你选择了有某些意义的正确的单词结束了句子。

Farhana:OK，这意味着什么呢？

Shubho:面向对象原则与这类似。OOP指的是面向对象编程的基本原则和核心思路。在这里，OOP可以比作英语基础语法，这些语法教你如何用单词构造有意义且正确的句子，OOP教你在代 码中构造类，并在类里封装属性和方法，同时构造他们之间的层次关系。

Farhana:嗯..我有点感觉了，这里有OOD吗？

Shubho:马上就有答案。现在假定你需要就某些主题写几篇文章或随笔。你也希望就几个你擅长主体写几本书。对写好文章/随笔或书来说，知道如何造句是不够的，对吗？为了使读者能更轻 松的明白你讲的内容，你需要写更多的内容，学习以更好的方式解释它。

Farhana:看起来有点意思...继续。

Shubho:现在，如果你想就某个主题写一本书，如学习OOD，你知道如何把一个主题分为几个子主题。你需要为这些题目写几章内容，也需要在这些章节中写前言，简介，例子和其他段落。 你需要为写个整体框架，并学习一些很好的写作技巧以便读者能更容易明白你要说的内容。这就是整体规划。

在软件开发中，OOD是整体思路。在某种程度上，设计软件时，你的类和代码需能达到模块化，可复用，且灵活，这些很不错的指导原则不用你重新发明创造。确实有些原则你已经在你的类和对象中已经用到了，对吗？

Farhana:嗯...有个大概的印象了，但需要继续深入。

Shubho:别担心，你马上就会学到。我们继续讨论下去。

Shubho:这是一个非常重要的问题。当我们能很快地设计一些类，完成开发并发布时，为什么我们需要关心OOD？那样子还不够吗？

Farhana:嗯，我早先并不知道OOD，我一直就是开发并发布项目。那么关键是什么？

Shubho:好的，我先给你一句名言：

走在结冰的河边不会湿鞋，开发需求不变的项目畅通无阻(Walking on water and developing software from a specification are easy if both are frozen)

-Edward V.Berard

Farhana:你的意思是软件开发说明书会不断变化？

Shubho:非常正确！软件开发唯一的真理是“软件一定会变化”。为什么?

因为你的软件解决的是现实生活中的业务问题，而现实生活中得业务流程总是在不停的变化。

假设你的软件在今天工作的很好。但它能灵活的支持“变化”吗？如果不能，那么你就没有一个设计敏捷的软件。

Farhana:好，那么请解释一下“设计敏捷的软件”。

Shubho:"一个设计敏捷的软件能轻松应对变化，能被扩展，并且能被复用。"

并且应用好"面向对象设计"是做到敏捷设计的关键。那么，你什么时候能说你在代码中很好的应用了OOD？

Farhana:这正是我的问题。

Shubho:如果你代码能做到以下几点，那么你就正在OOD：

• 面向对象
• 复用
• 能以最小的代价满足变化
• 不用改变现有代码满足扩展

Farhana：还有？

Shubho:我们并不是孤立的。很多人在这个问题上思考了很多，也花费了很大努力，他们试图做好OOD，并为OOD指出几条基本的原则(那些灵感你能用之于你的OOD)。他们最终也确实总结出了一些通用的设计模式(基于基本的原则)。

Farhana:你能说几个吗？

Shubho:当然。这里有很多涉及原则，但最基本的是叫做SOLID的5原则(感谢Uncle Bob,伟大OOD导师)。

接下去，我们会仔细探讨每一个原则。

Shubho:我先给你展示一张海报。我们应当谢谢做这张海报的人，它非常有意思。

单一职责原则海报

它说："并不是因为你能，你就应该做"。为什么？因为长远来看它会带来很多管理问题。

从面向对象角度解释为："引起类变化的因素永远不要多于一个。"

或者说"一个类有且只有一个职责"。

Farhana：能解释一下吗？

Shubho:当然，这个原则是说，如果你的类有多于一个原因会导致它变化(或者多于一个职责)，你需要一句它们的职责把这个类拆分为多个类。

Farhana:嗯...这是不是意味着在一个类里不能有多个方法？

Shubho:不。你当然可以在一个类中包含多个方法。问题是，他们都是为了一个目的。如今为什么拆分是重要的？

那是因为：

• 每个职责是轴向变化的；
• 如果类包含多个职责，代码会变得耦合；

Farhana:能给我一个例子吗？

Shubho:当然，看一下下面的类层次。当然这个例子是从Uncle Bob那里得来，再谢谢他。

违反单一职责原则的类结构图

这里，Rectangle类做了下面两件事：

• 计算矩形面积；
• 在界面上绘制矩形；

并且，有两个应用使用了Rectangle类：

• 计算几何应用程序用这个类计算面积；
• 图形程序用这个类在界面上绘制矩形；

这违反了SRP(单一职责原则);

Farhana:如何违反的？

Shubho:你看，Rectangle类做了两件事。在一个方法里它计算了面积，在另外一个方法了它返回一个表示矩形的GUI。这会带来一些有趣的问题：

在计算几何应用程序中我们必须包含GUI。也就是在开发几何应用时，我们必须引用GUI库；

图形应用中Rectangle类的变化可能导致计算几何应用变化，编译和测试，反之亦然；

Farhana:有点意思。那么我猜我们应该依据职责拆分这个类，对吗？

Shubho:非常对，你猜我们应该做些什么？

Farhana:当然，我试试。下面是我们可能要做的：

拆分职责到两个不同的类中，如：

• Rectangle:这个类应该定义Area()方法；
• RectangleUI:这个类应继承Rectangle类，并定义Draw()方法。

Shubho:非常好。在这里，Rectangle类被计算几何应用使用，而RectangleUI被图形应用使用。我们甚至可以分离这些类到两个独立的DLL中，那会允许我们在变化时不需要关心另一个就可以实现它。

（编辑：安卓应用网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!