《Head First设计模式》第一部分——设计模式入门

文章目录第一部分:设计模式入门
前言
这本书是Head First系列书籍,这一系列的书籍都是为了“深入浅出”而出版的,设计模式是前人总结的一些让程序的编写更顺畅的经验,但是因为Gof所著的《设计模式》有些不太容易阅读,对于不容易阅读的书,往往会有已经悟道的人写出白话版或注释版,用更直白的方式阐述其中的道理,来让更多的人学
习 。
本书有13章 , 完整涵盖了四人组版本全部23个设计模式,当然,完全不止这23个设计模式 , 后面还会说很多其它的设计模式以及复合设计模式 。
这本书真的很有趣,推荐给你 。真的很有趣 , 让我见识到了具有多领域知识的作者融合到一起,会有特别出奇的效果 。
引子
这是本书的第一部分,我原本认为这部分可能不是很重要,但是它却教的是我们如何去学习设计模式,或者说,是如何去学习 。恍惚间还以为自己在学习认知学习的课程 。
如何使用这本书
下面是一些Head First学习原则:
1、看得到
与单纯文字相比,图片更能让人记得?。ü计?nbsp;, 学习效率会更高,而且图片更能让人看懂 。另外,如果把图片放在与之相关的图片内部或者在图片的周围写上相关文字 , 学习者的能力就能得到多至两倍的提高 。
2、采用一种针对个人的交谈式风格
最新研究表明,如果学习过程中采用一种第一人称的交谈方式直接向读者讲述有关内容,而不是用一种干巴巴的语调介绍,学生在学习之后的考试之中成绩会提高40%,正确的做法是讲故事而不是汇报 。
3、让学习的人想得更深
换句话说,除非你很积极地让神经元活动起来,否则你的头脑里什么也不会发生,必须引起读者的好奇 , 促进,要求并鼓励读者去解决问题 , 得出结论,产生新的知识,为此,需要提出挑战,留下习题并拓宽思路的问题 。
4、引起读者的注意,并且要让他一直保持注意
你的大脑注意的是那些不一般、有意思、有些奇怪、抢眼的、意料之外的东西,学习一项有难度的新技术不一定枯燥 , 如果学习过程不乏味,你的大脑很快就能学会 。
5、影响读者的情绪
如果是你关心的东西,你就肯定能记?。?如果让你感受到什么,这些东西就会留在你的脑海里,但是我们在这里所说的情绪不是指伤心与难过,而是惊讶、好奇、觉得有趣,想知道“什么……”,还有就是自豪感,如果你解决了难题,学会了大家都觉得难的东西,或者你发现你了解的一些知识竟然是那些自以为无所不能的傲慢家伙所不知道的,此时就会有一种自豪感油然而生 。
元认知:有关思考的思考
如何才能记住你想记住的内容呢?
你的大脑会记住那些它决不允许在次发生的事情,比如你只身短衣在冰天雪地里的场景,如果你想要你的大脑最大程度的掌握这本书的内容 , 就要让你的大脑负起责任来,技巧在于要让你的大脑认为你在学习的新东西确实很重要,对你的生活有很大的影响 , 就像一只饥饿的老虎出现在你的面前一样 。,否则,你将陷入旷日持久的拉锯战中,虽然你很想记住所学的新内容 , 但是你的大脑却会竭尽全力地把它们拒之门外 。
那么,如何才能让你的大脑把设计模式看作是一只饥饿的老虎呢?
有两条路:

《Head First设计模式》第一部分——设计模式入门

文章插图
第一条路比较慢,很乏味 , 就是大量的重复 , 如果反反复复地看到同一个东西,就算再没有意思,你也能学会并记住它 。如果做足够了反复,你的大脑就会想“尽管看上去这对他来说好像不重要 , 不过,既然他这样一而再、再而三地看同一个东西,那么我就假定这是很重要的 。”
第二条路很快 , 而且更有效,就是尽一切可能让大脑活动起来 , 特别是开动大脑来完成不同类型的活动,前面的学习原则就是一些主要的可取做法 。
另外可以尝试在学习中嵌入这些方法 。
本书特点
没有包含所有的设计模式:无法包含,太多了 。
对于很多概念安排了许多重复
代码示例尽量短小精悍
习题没有答案
第一部分:设计模式入门
学习设计模式的过程就是经验复用的过程
模拟鸭子应用
背景是这样的:
Joe上班的公司做了一套相当成功的模拟鸭子游戏: 。游戏中会出现各种鸭子,一边游泳戏水,一边呱呱叫 。此系统的内部设计使用了标准的OOP技术,设计了一个鸭子超类(),并让各种鸭子继承此超类 。
利用继承
这是很好理解的是吧?就是OOP的思想,由于子类都用呱呱叫和游泳的特性,所以直接继承 , 但是显示方法每一个鸭子可能都不一样 , 所以是抽象的,由各个子类自己实现自己的显示方法 。
接下来,公司主管想要进行一些创新 , 他们需要会飞的鸭子有飞的能力 。
于是,Joe就在父类中加了一个fly()方法 。
可怕的事情发生了,测试的时候 , 有很多的“橡皮鸭子”在屏幕上飞来飞去,主管很生气!
这是因为Joe在Duck超类中加上了新的行为,会使得某些并不适合该行为的子类也具有该行为 。
于是Joe就想 , 可以用继承把父类的方法覆盖掉 。
书本给了一个思考题:
没有答案 。
我选择:
A:因为这样会导致,如果我接下来有100种鸭子是不具有飞的特性的,而继承了这个父类 , 导致我需要在100种鸭子类中都覆盖fly()方法,实行空操作,这不仅表示父类的代码没有什么复用性 , 而且还增加了很多不必要的代码 。
B:飞也有它独特的特性,你是能斜着飞,还是能垂直着飞?如果所有的子类都继承一个父类,而父类把飞的特性给写死了的话,说明如果我们的子类需要增加或者修改父类“飞”的特性的时候 , 就需要重写代码,这就导致父类的代码的复用性很差 。
F:如果因为一些原因改变了父类的代码,就会导致所有继承这个父类的鸭子,关于这个代码的逻辑发生改变 , 很容易出现问题 。
利用接口
Joe认识到继承可能不是最终的答案 。于是Joe尝试用接口来实现这一效果,
但是这样有很大的问题:
它意味着你每当有一种鸭子需要实现fly()或quack()方法的时候,你都要在这个类里实现一遍fly()或quack()方法,这样代码根本没有复用性而言 。就算两种鸭子的飞行行为是一致的 , 也需要写两遍 。
虽然这种方式可以解决“不会再有会飞的橡皮鸭”,但是却造成了大量的代码的冗余,大大增加了工作量 。
那么接下来就要引入软件开发的一个不变真理!
不管当初软件设计得多好,一段时间之后 , 总是需要成长与改变,
否则软件就会“死亡 。”
而驱动改变的因素很多,找出你的应用中需要改变代码的原因,一一列出来:
我们出现了Bug,需要进行更新和维护 。
我们的程序执行的效率不高,需要优化或者重构 。
好了,现在我们又回归到了原点,我们知道继承并不能很好的解决问题 , 因为鸭子的行为在子类里不断的改变,并且让所有的子类都有这些行为是不合理的 。
而与接口一开始似乎还不错,但是Java的接口不具有实现代码 , 所以继承接口无法达到代码的复用 。
那怎么办呢? 。。。
未完待续 。。。。。。
感兴趣的话 , 可以去书里看看 。
【《Head First设计模式》第一部分——设计模式入门】祝秋安