监控网站开发,轴承推广做哪个网站,北京代理记账公司排名前十强,农村自建房设计师哪里找前言 此文译自CodeProject上How I explained OOD to my wife一文#xff0c;该文章在Top Articles上排名第3#xff0c;读了之后觉得非常好#xff0c;就翻译出来#xff0c;供不想读英文的同学参考学习。 作者(Shubho)的妻子(Farhana)打算重新做一名软件工程师(她… 前言 此文译自CodeProject上How I explained OOD to my wife一文该文章在Top Articles上排名第3读了之后觉得非常好就翻译出来供不想读英文的同学参考学习。 作者(Shubho)的妻子(Farhana)打算重新做一名软件工程师(她本来是后来因为他们孩子出生放弃了)于是作者就试图根据自己在软件开发设计方面的经验帮助她学习面向对象设计(OOD)。 自作者从事软件开发开始作者常常注意到不管技术问题看起来多复杂如果从现实生活的角度解释并以对答的方式讨论那么它将变得更简单。现在他们把在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:别担心你马上就会学到。我们继续讨论下去。 为什么要OOD 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导师)。 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:对的。下面是正确的设计。 遵循开放闭合原则的类结构 在这个例子中添加了一个抽象的服务器类客户端包含一个抽象类的引用具体的服务类实现了抽象服务类。那么因任何原因引起服务实现发生变化时客户端都不需要任何改变。 这里抽象服务类对修改是闭合的实体类的实现对扩展是开放的。 Farhana:我明白了抽象是关键对吗 Shubho:是的基本上你抽象的东西是你系统的核心内容如果你抽象的好很可能在扩展功能时它不需要任 何修改(就像服务是一个抽象概念)。如果在实现里定义了抽象的东西(比如IIS服务器实现的服务)代码要尽可能以抽象(服务)为依据。这会允许你扩展抽 象事物定义一个新的实现(如Apache服务器)而不需要修改任何客户端代码。 Liskovs 替换原则 Shubho:Liskovs替换原则(LSP)听起来很难却是很有用的基本概念。看下这幅有趣的海报 Liskov替换原则海报 这个原则意思是子类型必须能够替换它们基类型。 或者换个说法使用基类引用的函数必须能使用继承类的对象而不必知道它。 Farhana:不好意思听起来有点困惑。我认为这个OOP的基本原则之一。也就是多态对吗为什么一个面向对象原则需要这么说呢 Shubho:问的好。这就是你的答案 在基本的面向对象原则里继承通常是is a的关系。如果Developer 是一个SoftwareProfessional,那么Developer类应当继承SoftwareProfessional类。在类设计中Is a关系非常重要但它容易冲昏头脑结果使用错误的继承造成错误设计。 Liskov替换原则正是保证继承能够被正确使用的方法。 Farhana:我明白了。有意思。 Shubho:是的亲爱的确实。我们看个例子 Liskov替换原则类结构图 这里KingFisher类扩展了Bird基类并继承了Fly()方法这看起来没问题。 现在看下面的例子 违反Liskov替换原则类结构图 Ostrich(鸵鸟)是一种鸟(显然是),并从Bird类继承。它能飞吗不能这个设计就违反了LSP。 所以即使在现实中看起来没问题在类设计中Ostrich不应该从Bird类继承这里应该从Bird中分离一个不会飞的类Ostrich应该继承与它。 Farhana:好明白了。那么让我来试着指出为什么LSP这么重要 如果没有LSP类继承就会混乱如果子类作为一个参数传递给方法将会出现未知行为如果没有LSP适用与基类的单元测试将不能成功用于测试子类对吗 Shubho:非常正确。你能设计对象使用LSP做为一个检查工作来测试继承是否正确。 接口分离原则 Shubho:今天我们学习接口分离原则,这是海报 接口分离原则海报 Farhana:这是什么意思 Shubho:它的意思是客户端不应该被迫依赖于它们不用的接口。 Farhana:请解释一下。 Shubho:当然这是解释 假设你想买个电视机你有两个选择。一个有很多开关和按钮它们看起来很混乱且好像对你来说没必要。另一个只有几个开关和按钮它们很友好且适合你使用。假定两个电视机提供同样的功能你会选哪一个 Farhana:当然是只有几个开关和按钮的第二个。 Shubho:对但为什么 Farhana:因为我不需要那些看起来混乱又对我没用的开关和按钮。 Shubho:以便外部能够知道这些类有哪些可用的功能,客户端代码也能根据接口来设计.现在,如果接口太大,包含很多暴露的方法,在外界看来会很混乱.接口包含太多的方法也使其可用性降低,像这种包含了无用方法的胖接口会增加类之间的耦合.你通过接口暴露类的功能,对.同样地,假设你有一些类, 这也引起了其他问题.如果一个类想实现该接口,那么它需要实现所有的方法,尽管有些对它来说可能完全没用.所以说这么做会在系统中引入不必要的复杂度,降低可维护性或鲁棒性. 接口隔离原则确保实现的接口有他们共同的职责,它们是明确的,易理解的,可复用的. Farhana:你的意思是接口应该仅包含必要的方法,而不该包含其它的.我明白了. Shubho:非常正确.一起看个例子. 下面是违反接口隔离原则的一个胖接口 注意到IBird接口包含很多鸟类的行为,包括Fly()行为.现在如果一个Bird类(如Ostrich)实现了这个接口那么它需要实现不必要的Fly()行为(Ostrich不会飞). Farhana:确实如此。那么这个接口必须拆分了 Shubho:是的。这个胖接口应该拆分未两个不同的接口IBird和IFlyingBird,IFlyingBird继承自IBird. 这里如果一种鸟不会飞(如Ostrich)那它实现IBird接口。如果一种鸟会飞(如KingFisher)那么它实现IFlyingBird. Farhana:所以回头看包含了很多开关和按钮的电视机的例子电视机制造商应该有一个电视机的图纸开关和按钮都在这个方案里。不论任何时候当他们向制造一种新款电视机时如果他们想复用这个图纸他们将需要在这个方案里添加更多的开关和按钮。那么他们将没法复用这个方案对吗 Shubho:对的。 Farhana:如果他们确实需要复用方案它们应当把电视机的图纸份为更小部分以便在任何需要造新款电视机的时候复用这点小部分。 Shubho:你理解了。 依赖倒置原则 Shubho:这是SOLID原则里最后一个原则。这是海报 它的意思是高层模块不应该依赖底层模块两者都应该依赖其抽象 Shubho:考虑一个现实中的例子。你的汽车是由很多如引擎车轮空调和其它等部件组成对吗 Farhana:是的 Shubho:好它们没有一个是严格的构建在一个单一单元里换句话说它们都是可插拔的因此当引擎或车轮出问题时你可以修理它(而不需要修理其它部件),甚至可以换一个。 在替换时你仅需要确保引擎或车轮符合汽车的设计(如汽车能使用任何1500CC的引擎或任何18寸的车轮)。 当然汽车也可能允许你在1500CC引擎的地方安装一个2000CC的引擎事实上对某些制造商(如丰田汽车)是一样的。 现在如果你的汽车的零部件不具备可插拔性会有什么不同 Farhana:那会很可怕因为如果汽车的引擎出故障了你可能修理整部车或者需要买一个新的。 Shubho:是的那么该如何做到可插拔性呢 Farhana:这里抽象是关键对吗 Shubho:是的在现实中汽车是高级模块或实体它依赖于低级模块或实体如引擎或车轮。 相比直接依赖于引擎或车轮汽车应依赖于某些抽象的有规格的引擎或车轮以便于如果任何引擎或车轮符合抽象那么它们都能组合到汽车中汽车也能跑动。 一起看下面的类图 Shubho:注意到上面Car类有两个属性它们都是抽象类型(接口)。引擎和车轮是可插拔的因为汽车能接受任何实现了声明接口的对象并且Car类不需要做任何改动。 Farhana:所以如果代码中不用依赖倒置我们将面临如下风险 使用低级类会破环高级代码 当低级类变化时需要很多时间和代价来修改高级代码 产生低复用的代码 Shubho:你完全掌握了亲爱的 总结 Shubho除SOLID原则外还有很多其它的面向对象原则。如 组合替代继承:这是说相对于继承要更倾向于使用组合 笛米特法则这是说你的类对其它类知道的越少越好 共同封闭原则这是说相关类应该打包在一起 稳定抽象原则这是说类越稳定越应该由抽象类组成; Farhana:我应该学习那些原则吗 Shubho:当然可以。你可以从整个网上学习。仅仅需要Google一下那些原则然后尝试理解它。当然如果有需要尽管问我。 Farhana:在那些设计原则之上我听说过很多设计模式。 Shubho:对的。设计模式只是对一些经常出现的场景的一些通用设计建议。这些灵感主要来自于面向对象原则。你可以把设计模式看作框架,把OOD原则看作规范. Farhana:那么接下去我将学习设计模式吗 Shubho:是的亲爱的。 Farhana:那会很有意思对吗 Shubho:是那确实令人兴奋。 转载于:https://www.cnblogs.com/xyqCreator/archive/2012/10/23/2735234.html
