【设计模式】【综述】

  参考资料:《大话设计模式》

  PS:引用了很多书中的内容,特此标注出处。

  面向对象思想是软件工程领域的一种哲学世界观,相比于更为直观的面向过程化,它处理问题的角度和方法都有些不同。而设计模式就相当于在这种世界观指导下而形成的方法论。通俗来说,就是当遇到了某种特定环境下的问题,设计模式提供了一种符合面向对象原则的处理办法,它是无数程序员经历了许久历练而总结出来的经验论,依循这些设计模式的思路,你可以对面向对象思想有更加深刻的理解,你可以对面向对象的设计原则有着更加深刻的把握,甚至于,你可以淡化设计模式中的具体方法,提取出其中的精髓,创造出适合于自己所遇到的实际问题中的设计模式!

  面向过程化的思想是指在面对问题的时候,通过分析和把握问题的本质,对问题的解决方案进行处理,总结出一个流程,流程中的具体步骤就对应了一个function。从代码角度来看待这个思想,那么它的基本组成单位就是function,通常的面向过程化语言需要有一个主function,称之为main,它作为函数的入口。因此,倘若你遇到的是一个算法问题(如ACM算法题),那么你会发现面向过程化语言在处理这个问题上体现出的简洁与高效。

  然而当问题发展到一定的规模时候,简洁与高效的优先级也许就没有那么高了。比如,你的需求发生了变更,需要修改代码时候,怎么办?在面向过程化的代码中,我需要打开代码,将整个问题的流程进行更正,运气不好甚至要重新编写一份代码。再比如,你的数据关系到了一些机密的信息,比如银行账户的密码,怎么办?在面向过程化的代码中,你无法处理这种情况,因为变量总是轻易地暴露在调用者的程序中,他可以随意地使用修改它。又比如,你发现代码中有很多地方重复书写了好多遍,但是其中又有少许不同,怎么办?在面向过程化的代码中,也许你会想到提取公共的部分到一个function中,然后对于不同部分使用参数列表去适应它的变化,然后这种变化的情况太复杂了,参数的个数会有不定个,种类会有不定种,总之你无法调配出一个合适于所有情况的参数列表。

  综上所述,面向过程化在处理一些大规模的现实应用问题方面,将显得力不从心。然而这并不意味着面向过程化的思想和语言需要摒弃,事实上,C语言仍然是世界上使用最多最为优秀的编程语言之一。究其原因,个人理解,这是一个“什么更加重要”的问题,当你去写一个操作系统的内核,你更愿意考虑它的什么因素?当你去写一个企业级网站,你更愿意考虑它的什么因素?要知道,一个云平台的应用,是面向了亿万级别的用户,那么其中的万分之一秒的时间优化,也许就为它的公司省下了一部大型机器。这个时候,时间和效率的优先级很高。

  所以,面向过程化和面向对象都有着它们的适用领域,二者之间也并非是对立关系。面向对象建立在了更粗的粒度上面,它将function之间的联系互动提升到了object这个级别,一个object有其attribution和operation,每个object可以看成是一个特殊的个体,那么个体的共性,就可以抽象成为class。

  既然要谈面向对象,那么就要基于class和object去谈,就像化学家对世界的认知是:万物是原子、分子构成的一样,我们不需要去费劲地解释那些名词的概念,从代码的角度来研究也许会是更好的理解方法,有时候,说不出来不代表不懂,只是那种理不清道不明的感觉很奇特,然而当你实际地敲上几行代码,是朽木还是真金就高下立判。后续的详细篇内容将会加入实际的代码与UML图去帮助理解。

  面向对象的三大基本特征:

  1、封装:隐藏实现的细节,隐藏私密的数据,暴露共有的接口与方法来进行class、object之间的互动。

  2、继承:由父类衍生出行为与其相似但不完全相同的子类,为了提升代码的可扩展性。

  3、多态:对象的具体行为由它的运行时类型来决定,一个相同的对象,在不同的环境下表现出不同的行为。

  这里再次强调,对一些概念费劲地去解释,不是一个学习它的好办法,因为解释概念只能记住一时,不易理解,所以很快就会遗忘。

  

  面向对象设计的六大原则:

  这里强调一下,原则并不是规则,不是说违反了某条原则就不是一个很好的面向对象设计。这里的原则是指在遇到这类的问题时候,最好去依循这些原则的想法来处理,但万不得已要违反,也就真的违反了。比如:当需求变更时候,我需要依循开放封闭原则,对扩展开放,对修改封闭,也就是说尽量通过添加代码的方式来实现对变更需求的响应,但是,需求变更就意味着你的代码一定要发生修改,不可能一成不变。所以这在一定角度来看,也确实违反了对修改封闭这条原则。但是这是不可避免的必要过程,因此不要将原则视为法则一样不可违背。设计模式的精髓就在于面对不可逆转的情况下,让一个问题的解决更多更好的遵循这些原则,而遵循这些原则会带来的主要好处就是:软件的安全性、可扩展性、可复用性提升了N个数量级。

  1、单一职责原则:类的设计要功能单一,引起类变化的原因最好是只有一个。简单说,就是一个类最好只有一个功能,不要把杂七杂八的通通写在一起。

  2、开放封闭原则:软件模块要对扩展开放,对修改封闭。意思是,当你的功能要改或者要拓展的时候,最好是添加代码来实现这个变更的响应,而不是通过打开原有代码去修改来实现这个变更的响应。

  3、里氏代换原则:一个父类在任何时候要能够被其子类替换,并且让人看不出来。在生物学上,有遗传和变异,因此一个父亲可能有着与他差异很大的子女,但是这违背了里氏代换原则,里氏代换并不包括了那些变异。简单来说,就是一个子类不能够包含违反其父类定义的属性或方法,比如,鸵鸟作为鸟的子类,鸟有个operation是fly(),而鸵鸟并不会飞,那么鸵鸟作为鸟的子类这个设计就违反了里氏代换原则,它将不会是一个好的面向对象设计。

  4、迪米特原则:也称为最少知识原则。意思是,如果两个类之间没有必要直接互相联系,那么就没有必要让两个类耦合,最好的处理方式是通过第三方来作为中介来联系。也许你看了之后会觉得这不是更加麻烦了么。但试想,如果这样的类多了起来,那么它们之间的关系将显得极其复杂,就如同现今的国家间关系一样。而联合国的存在就类似于这个中介者,它将各个国家之间的复杂关系通过它来进行传达,从而大大简化了国家之间的联系关系。

  5、依赖倒置原则:高层组件不要依赖于底层组件,抽象不要依赖具体实现,具体实现要依赖抽象。简单点说,就是在设计类的时候,先提供它的接口。具体的实现则不在考虑范围之内,反正你无论怎样去实现,功能都是一样的。这也便于当我们发现实现可以进行优化时候,只需要修改它的具体实现,而不需要去变更其它的部分。

  6、合成复用原则:尽量多地去使用合成,而不要使用继承。继承天生是一种父类与子类的高耦合性设计,因此,当父类需要进行变更的时候,子类就难以避免会随之产生变更,有可能需要重新设计子类,这样维护代价就太高了。而合成则没有这种情况,因此更多时候优先考虑合成。然而如果要使用继承通常也就是必须使用继承了,因此,这条原则并不需要刻意地去默念遵守。

  

  站在面向对象的角度看问题,class和object是它的基本单位。那么设计模式就是人们在研究class和object的创建、组成和行为的过程。

  首先,人们研究如何地创建一个类或者对象,能够使得创建的成本更低、更易于维护、更易于复用,于是就有了创建对象的一些设计模式:

  1、简单工厂模式

  2、工厂方法模式

  3、抽象工厂模式

  4、建造者模式

  5、单例模式

  6、原型模式

  

  创建好了类和对象之后,对于它们之间的组合关系进行研究,去发掘它们更好的组合形式,于是有了组合对象的一些设计模式:

  1、组合器模式

  2、桥接模式

  3、装饰器模式

  4、适配器模式

  5、享元模式

  6、代理模式

  7、外观模式

  创建好了,也找到了它们之间合适的组合方式,那么下一步便是对它们之间的行为进行一个研究,于是有了行为型的设计模式:

  1、策略模式

  2、模板方法模式

  3、命令模式

  4、观察者模式

  5、备忘录模式

  6、状态模式

  7、迭代器模式

  8、责任链模式

  9、解释器模式

  10、中介者模式

  11、访问者模式    

  

  之后的详细篇将会对以上内容进行详细地展示与说明。

时间: 2024-10-05 06:47:00

【设计模式】【综述】的相关文章

课堂作业06——设计模式综述

设计模式综述 1.简单工厂模式 简单工厂模式中,有一个专门负责创建其他实例的类--工厂类,这个类可以动态地调用需要的类来完成相应的功能,只要传入一个正确参数即可.就像用户想要水果,但并不需要知道水果是如何创建的. 2.工厂方法模式 与简单工厂不同的是,工厂方法模式将工厂类负责的创建功能交给子类去做,因而增加了接口功能,将重点放在具体的类上.此模式的优点是方便增加功能,更加注重创建对象的细节,但缺点是类的个数会增加,使代码更不容易理解. 3.抽象工厂模式 抽象工厂模式是工厂方法的泛化版,这个工厂可

一些基本的设计模式综述

设计模式分为三种类型,共23类. 创建型模式:单件模式.抽象工厂模式.建造者模式.工厂方法.原型模式. 结构型模式:适配器模式.桥接模式.装饰模式.组合模式.外观模式.享元模式.代理模式. 行为型模式:模版方法模式.命令模式.迭代器模式.观察者模式.中介者模式.备忘录模式.解释器模式.状态模式.策略模式.职责链模式.访问者模式. Abstract Factory(抽象工厂模式):提供一个创建一系列相关或相互依赖对象的接口,而无需指定它们具体的类. Adapter(适配器模式):将一个类的接口转换

设计模式综述

1. 设计模式 设计模式(Design pattern)是一套被反复使用.多数人知晓的.经过分类编目的.代码设计经验的总结.使用设计模式是为了可重用代码.让代码更容易被他人理解.保证代码可靠性. 毫无疑问,设计模式于己于他人于系统都是多赢的,设计模式使代码编制真正工程化,设计模式是软件工程的基石,如同大厦的一块块砖石一样.      模式的经典定义:每个模式都描述了一个在我们的环境中不断出现的问题,然后描述了该问题的解决方案的核心,通过这种方式,我们可以无数次地重用那些已有的解决方案,无需再重复

综述:设计模式的分类及六大原则

一.设计模式的分类 总体来说设计模式分为三大类: 创建型模式,共五种:工厂方法模式.抽象工厂模式.单例模式.建造者模式.原型模式. 结构型模式,共七种:适配器模式.装饰器模式.代理模式.外观模式.桥接模式.组合模式.享元模式. 行为型模式,共十一种:策略模式.模板方法模式.观察者模式.迭代子模式.责任链模式.命令模式.备忘录模式.状态模式.访问者模式.中介者模式.解释器模式. 其实还有两类:并发型模式和线程池模式.用一个图片来整体描述一下: 二.设计模式的六大原则 1.开闭原则(Open Clo

设计模式开篇综述(Java)

设计原则是规范,设计模式是技巧.如果在项目中能够灵活运用这些基础知识,那么我相信一定会得到意想不到的收获. 接下来的时间里,我将继续学习设计模式,将对每一个设计模式从以下几点进行分析和学习,如有不妥当或者理解错误的地方,欢迎大家指正和批评: (1) 定义:描述该模式是什么,有什么样的作用: (2) 问题描述:该模式是针对什么样的问题而出现的,由开发中遇到的问题而引入: (3) 解决方案:给出合适的解决方案,进一步解释该模式的定义: (4) 结构图:根据定义,绘制相关栗子的UML结构图: (5)

Map 综述(二):彻头彻尾理解 LinkedHashMap

摘要: HashMap和LinkedList合二为一即是LinkedHashMap.所谓LinkedHashMap,其落脚点在HashMap,因此更准确地说,它是一个将所有Entry节点链入一个双向链表LinkedList的HashMap.由于LinkedHashMap是HashMap的子类,所以LinkedHashMap自然会拥有HashMap的所有特性.比如,LinkedHashMap的元素存取过程基本与HashMap基本类似,只是在细节实现上稍有不同.当然,这是由LinkedHashMap

Java设计模式之观察者模式

综述 观察者模式(Observer Pattern)也叫做发布-订阅(Publish/Subscribe)模式.模型-视图(Model/View)模式.这个模式的一个最重要的作用就是解耦.也就是将被观察者和观察者进行解耦,使得他们之间的依赖性更小,甚至做到毫无依赖.在观察者模式中它定义了一种一对多的依赖关系,使得当每一个对象改变状态,则所有依赖于它的对象都会得到通知并被自动更新.下面就来看一下观察者模式的具体实现. 观察者模式实现 在这里我们假定一个场景,在一个图书管理系统中,现在有这么一个需求

Atitit.架构设计趋势 设计模式 ---微服务架构  soa

Atitit.架构设计趋势 设计模式 ---微服务架构  soa 什么是微服务架构?1 .微服务与SOA的关系 :微服务架架构师面向服务架构(SOA)的一种特定实现1 微服务与康威定律2 微服务的一些设计 断路器 幂等2 <微服务设计>([英] 纽曼(Sam Newman))3 微服务架构与实践4 什么是微服务架构? Martin Fowler认为,微服务架构是一种独立部署的软件应用设计方式.这种架构方式没有准确的定义,但是在业务能力.自动部署.端对端的整合.对语言及数据的分散控制上有着共性.

两种高性能I/O设计模式(Reactor/Proactor)的比较

综述 这篇文章探讨并比较两种用于TCP服务器的高性能设计模式. 除了介绍现有的解决方案,还提出了一种更具伸缩性,只需要维护一份代码并且跨平台的解决方案(含代码示例),以及其在不同平台上的微调. 此文还比较了java.c#.c++对各自现有以及提到的解决方案的实现性能. 系统I/O 可分为阻塞型, 非阻塞同步型以及非阻塞异步型[1.2]. 阻塞型I/O意味着控制权只到调用操作结束了才会回到调用者手里. 结果调用者被阻塞了, 这段时间了做不了任何其它事情. 更郁闷的是,在等待IO结果的时间里,调用者