初步认识设计模式

  最近一直在想着学习设计模式,这里说的是面向对象领域的模式,找了些资料看了看,昨天也刚买了那本经典作品:设计模式-可复用面向对象软件的基础,只是看了下引言就收获很多,在这里把自己所能理解到的一些点点滴记录下来,算是自己的复习,也希望给大家一点帮助,希望能与大家多多交流学习,小弟感激不尽!以下这些是自己感觉挺有意义。今天只是做个简单开篇,GO!

  可复用面向对象的软件设计的基础!!从题目中我们可以看到它是在讲软件设计,而且是在面向对象的领域中所涉及到的软件设计问题,设计的目的之一就是为了软件方法的可复用性,当然这里所讲的只是一个软件设计的一个基础,重在思考,重在软件设计思想的培养。

  谈起设计模式,也许成为了一个古老的话题,整天思考着怎样去解决一个软件系统的实现问题,想着去写可复用、可扩展的的模块,如果没有软件的这些特殊性,特别是从时间角度来考虑软件的变化性,就这一点就决定着软件必须要面对和解决的一个不可逃避的问题,如果没有这些特殊性也许它(设计模式)不会被这么重视,而且应用设计模式也是有一定的代价,比如会设计更多的类,类与类之间的关系还要去了解等,也许对于软件开发的初学者(当然我也是^-^)来说学习这方面会有难度,因为经验少的原因,因为软件设计思想没有更好的培养等这些主观因素,当然这也是需要学习的原因了,设计模式不单单是书中讲的这23种,还有很多其他的,不过我感觉掌握这些模式的要领也不容易了,哈哈。

  自己的理解,设计模式它不仅仅是一种算法,更是一种可以解决重复问题的思想论,它是可以应用在一些特定场合来解决特定的软件问题的有效方法,相同的,也许处在别的环境中可能它并不是一个好的解决方法,或许它还会给软件带来累赘,所以不能乱用设计模式,要“对口”,所以在实现设计模式的原则中提出一条就是使用重构来实现模式,当然也有非常有经验有遇见性的设计大师或者一些很明显的应用模式的问题。

  每一个模式都描述了在软件开发中不断重复发生的问题,以及该问题的解决方案的核心,在以后的开发中就可以有经验的来复用这种模式。所以每个模式都有一个对整个过程有概括性的模式名称,现在想一下这23种设计模式,这些名称还真是起得相当的好!!在每个模式中都有四个要素,分别是:模式名称、问题、解决方案、效果。还是那句,正确使用模式的话会给软件系统带来绝对好的扩展性和灵活性,应用不好的话效果可想而知。

  要学习设计模式,在这里不得不提的重中之重就是面向对象的概念,大家说的抽象、封装、继承、多态,我想在脑袋中都刻成碑了!但重要的是要去理解这些概念,把这些概念"立体化"。

如果说设计模式够抽象,那一些设计原则更是体现在了模式的身上,也许大家都知道,在这里就简单的列一下:

  1、针对接口编程而不是针对实现编程。我们说继承是可复用的扩展的基本机制,继承可以很好的实现实现代码与客户的有效分离,使得客户程序不必了解具体实现,而实现只管它自己的事,在遇到可变性的问题时我只去扩展或进行少许改变就可以应对软件需求的变化(当然这是在设计模式应用合理的情况下。),这也就把职责进行了分离,在这些设计模式中大量用到了接口(我们说承继分为类继承与接口继承,都知道吧,呵呵)。

  2、优先使用对象组合,而不是类继承。上面刚说完接口多么的好,确实,继承实现了接口、类之间的可复用性与扩展性,但深刻考虑下,这种继承其实暗暗的造成了接口与实现之间的耦合关系,我们也称之为白箱复用,也就是说继承的类与类之间是相互了解的,所以在这里如果接口层要进行需求更改的话这些所以的关系都要进行一个复杂的改变,当然这个可以去解决,这也是这个原则存在的意义,使用对象组合,我们说这种关系是类与类之间的一种松耦合的实现方式,我们称之为黑箱复用,可以实现好的扩展性,在后面的结构型模式中把这种思想体现的非常秒!

  在这里需要肯定的一点是,继承与组合二者缺一不可,我们没有理由说谁好谁坏,所有的应用都是根据软件的特点来决定的。

  3、使用重构的方式得到模式。这一条我是从李建中老师的讲义上看到的,非常的有道理,可以说所有的模式都是经过不断的演变重构而成的,开发过程中不定会遇到什么样的问题,所以盲目的应用模式其实是对模式的一种不正确的使用,反而不会对软件的开发带来好处。

  以下列出了更具体的原则供大家参考:

  1、单一职责原则。这一原则体现了一个类只存在一个使它变化的原因,把类设计的职责很复杂看着就头晕!!!

  2、开放封装原则。这里提到的就是我们说的类是不可修改的,是可扩展的,虽然这样说,不过我是遇到就改。。哎。。。

  3、Liskov替换原则。子类必须能够替换它们的父类.

  4、依赖倒置原则。具体的说明:高层模块不应该领带于低层模块,二者都应该领带于抽象。抽象不应该依赖于实现细节,实现细节应该依赖于抽象。没得说,这条绝对重要!!

  5、接口隔离原则。这条原则告诉我们不应该把接口设计的非常复杂,只能去定义自己功能的抽象,子类不应该实现它不用的抽象。

  大体的就是这几个,当然还有别的一些原则了。如果说设计模式是绝世武功的招术,那这些原则就是心法了,可谓无招胜有招呀!哈哈!!

  突然想到书中介绍了一个在我们身边非常经典的组合模式的应用,窗体这个容器的实现,把一对多的关系实现成一对一的关系去解决问题,窗体容器即装载容器控件,也可以装载叶控件,而内部的容器控件又可以嵌套更多的子、叶控件!

  就这些了,有空再写具体的,以上有不合理的地方还请大家多指教!Over.

原文地址:https://www.cnblogs.com/quluqi/p/1659495.html