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:别担心你马上就会学到。我们继续讨论下去。为什么要OODShubho:这是一个非常重要的问题。当我们能很快地设计一些类完成开发并发布时为什么我们需要关心OOD那样子还不够吗Farhana:嗯我早先并不知道OOD我一直就是开发并发布项目。那么关键是什么Shubho:好的我先给你一句名言走在结冰的河边不会湿鞋开发需求不变的项目畅通无阻(Walking on water and developing software from a specification are easy if both are frozen)-Edward V. BerardFarhana:你的意思是软件开发说明书会不断变化Shubho:非常正确软件开发唯一的真理是“软件一定会变化”。为什么?因为你的软件解决的是现实生活中的业务问题而现实生活中得业务流程总是在不停的变化。假设你的软件在今天工作的很好。但它能灵活的支持“变化”吗如果不能那么你就没有一个设计敏捷的软件。Farhana:好那么请解释一下“设计敏捷的软件”。Shubho:一个设计敏捷的软件能轻松应对变化能被扩展并且能被复用。并且应用好面向对象设计是做到敏捷设计的关键。那么你什么时候能说你在代码中很好的应用了OODFarhana:这正是我的问题。Shubho:如果你代码能做到以下几点那么你就正在OOD面向对象复用能以最小的代价满足变化不用改变现有代码满足扩展Farhana还有Shubho:我们并不是孤立的。很多人在这个问题上思考了很多也花费了很大努力他们试图做好OOD并为OOD指出几条基本的原则(那些灵感你能用之于你的OOD)。他们最终也确实总结出了一些通用的设计模式(基于基本的原则)。Farhana:你能说几个吗Shubho:当然。这里有很多涉及原则但最基本的是叫做SOLID的5原则(感谢Uncle Bob,伟大OOD导师)。S 单一职责原则 Single Responsibility Principle O 开放闭合原则 Opened Closed Principle L Liscov替换原则 Liscov Substitution Principle I 接口隔离原则 Interface Segregation Principle D 依赖倒置原则 Dependency Inversion Principle接下去我们会仔细探讨每一个原则。单一职责原则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中那会允许我们在变化时不需要关心另一个就可以实现它。Farhana:谢谢我想我明白SRP了。SRP看起来是把事物分离成分子部分以便于能被复用和集中管理。我们也不能把SRP用到方法级别吗我的意思是我们可以写一些方法它们包含做很多事的代码。这些方法可能违反SRP对吗Shubho:你理解了。你应当分解你的方法让每个方法只做某一项工作。那样允许你复用方法并且一旦出现变化你能购以修改最少的代码满足变化。开放闭合原则Shubho:这里是开放闭合原则的海报开放闭合原则海报从面向对象设计角度看,它可以这么说:软件实体(类,模块,函数等等)应当对扩展开放对修改闭合。通俗来讲它意味着你应当能在不修改类的前提下扩展一个类的行为。就好像我不需要改变我的身体而可以穿上衣服。Farhana:有趣。你能够按照你意愿穿上不同的衣服来改变面貌而从不用改造身体。你对扩展开放了对不Shubho:是的。在OOD里对扩展开发意味着类或模块的行为能够改变在需求变化时我们能以新的不同的方式让模块改变或者在新的应用中满足需求。Farhana:并且你的身体对修改是闭合的。我喜欢这个例子。当需要变化时核心类或模块的源代码不应当改动。你能用些例子解释一下吗Shubho:当然看下面这个例子。它不支持开放闭合原则。违反开发闭合原则的类结构你看客户端和服务段都耦合在一起。那么只要出现任何变化服务端变化了客户端一样需要改变。Farhana:理解。如果一个浏览器以紧耦合的方式按照指定的服务器(比如IIS)实现那么如果服务器因为某些原因被其他服务器(如Apache)替换了那么浏览器也需要修改或替换。这确实很可怕Shubho:对的。下面是正确的设计。遵循开放闭合原则的类结构