程序员读书笔记

  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

文档来源为 :从网络收集整理 .word 版本可编辑 .欢迎下载支持 .

程序员读书笔记

导语:在接触到设计模式并能够稍微懂点的时间内,以

为面向对象这个东西的主要内容就是“设计模式”了吧。以

小编为大家介绍程序员读书笔记文章,仅供参考

程序员读书笔记刚开始编程的时候是在高中,那个

时候计算机课上老师教的是pasCal 。一种典型的面相过程的语

言。那个时候懵懵懂懂的认为:程序还是一个蛮神奇的东西,敲几

个英文字符进去,就能够有反馈。即使这个反馈只是非常简单的输

出了一个“ Hello World! ”。

而大学开始比较系统的学习计算机这个东西。但是现在

回想起来,貌似没有系统的学过程序设计这个东西啊。即使

了很多叫做《XXX 程序设计》的课程之后,对于程序设计这个

东西还是有种雾里看花的感觉。而且学的都是像汇编了,

C 了这样的一些比较底层的语言。主要是语法吧,设计层面

的东西真的很少。造成很长一段时间内,我对程序设计的认

知停留在高中pascal 的水平,程序设计就是你输入个东西,

然后设计一系列串行的逻辑,然后等着输出。

后来上了一个叫做《C++面向对象设计》的课,在上课

之前以为这是一个高大上的课程,结果到最后老师把C++讲

成了一个好用的C,比C优秀的地方主要就是在加了一些支持面向对

象的语法。现在回想一下,那些叫做《XXX程序设

1文档来源为 :从网络收集整理 .word 版本可编辑 .欢迎下载支持 .

计》的课程,基本上都是一些语言课程,貌似和程序“设计这个

东西有点不着边际。而也能够让我,对于“面向对象” 或者“面相

过程”构建起基本的概念。

我在写程序的时候,更多还是停留在pascal 那个层次

中。串行的逻辑。那个时候的梦想就是能够读完knuth 四卷

本的《The Art of program 》还有他为这本书写的辅导书《基本数学》。因为大家在程序=数据结构+算法的世界观中,这

几本书如同圣经。最后花了大概四五年吧,只读了第一卷的

300 多页。好吧,貌似我不是一个很虔诚的信徒。

有幸的是,大二开始跟着一个老师给他们当码农,敲代

码。就这样稀里糊涂,断断续续的以一个码农的角色在他们的项目

中敲敲打打。那时作为一个新手,得到最多的就是“埋汰”他们看着你写的C或者C++代码,说这个太不优雅了。

当时,我就想:靠,就是一串代码,又不是什么画,还能用

优雅来形容啊。之后,他们开始说一些设计模式了之类如同

天书的东西。大三下班学期的时候,有个哥们在搞magic linux 的安装程序的重构。我就听着他天天在和我白活写第

版安装程序的是如何如何牛逼哄哄的。模块划分的多么多

么清晰,模块间通信竟然都是用的xml。设计的可扩展性多

么多么好,模块间高耦合地内聚了。当时就觉得,靠,

真的很牛逼啊。用现在的一个词就是:不觉明历。不过当然,

得向牛逼的人学习。于是买了本C++版的《设计模式》,就是

最经典的那本。记得那个时候,读起来,略觉生涩。很多概

念都是囫囵吞枣的咽下去了。在以后的编程中,也能偶尔用

用什么观察者了,单例了之类的模式。偶尔,能够针对一些问题提出一些看似非常符合设计模式的“设计” 。

在接触到设计模式并能够稍微懂点的时间内,以为面向

对象这个东西的主要内容就是“设计模式”了吧。你看用了设计模式之后,腿也不酸了,要也不疼了,一口气能上十层楼了。写代码也开始有点那种玄乎的“优雅”的感觉了。切以为自己在码农这个职业上已经算是入门了。直到有一天看了一本叫做《敏捷开发》的书,才猛然间惊醒。他妈的,在设计模式之上还有六大原则:单一职责、里氏替换、开闭原则、迪米特法则、接口隔离原则、依赖倒置原则。原来设计模式被设计出来的时候也是按照一定的指导原则的,那就是六大原则。好吧,现在我的面向对象程序设计的思想库中又多了一批非常不错的概念:六大原则。而且惊喜的发现,随着对这六个原则尤其是单一职责原则的深入理解。自己开始,能够慢慢跳出原先那种刻意去使用设计模式的牢笼。开始去关注程序设计本身,或者说具体情况相关的东西。而不是为了设计去设计。这个时候,才开始慢慢的体会到其实程序设计这个东西真的并不是简单的逻辑罗列,而是思想的结晶。

是必须经过深思熟虑之后,才能完成的事情。不再一听到别人高谈阔论高内聚低耦合,就不觉明历,开始尝试着去思考

他们所谓的高内聚低耦合到底是个什么东西,用这个标准来评判一个面相对象的设计是否合适。这个面相过程的遗留品在面向对象的设计范畴内到底能够发挥多大的作用。渐渐的发现,其实高内聚低耦合和单一职责与迪米特法则是那么的貌离神合。讲的都是我们一段代码的职责一定要纯粹,而且越纯粹越好。不要染指其他代码的职责。登陆的代码就负责登陆,不需要管界面上的事情。界面上的代码就负责展示内容就好,不要负责业务逻辑。当能够清晰的指出系统中每个模块,每个类,甚至是每个函数那“单纯”的职责的时候,那么整个系统应该说是优雅的了吧。

而这个时候,进行分析与设计的时候总是有种捉襟见肘

的感觉,一个类的设计,甚至一个方法的定义与实现没有什么规矩可言。有些时候从上面说的六大原则和设计模式入手,大概构想出了软件的模样。但是到了一些编码细节上的时候,总是有种力不从心的感觉。简而言之,就是看手气写代码。

最终是否能够真实的还原自己的设计,完全是个靠经验吃饭的事情。而比较悲剧的是,作为一个编程经验没有十年二年的人来说,这似乎有点不太靠谱。作为一个数学系的学生,那种定理情节油然而生。难道就没有类似与定理一样的东西能够帮助我有效的还原设计,定义一个类,定义一个方法。

于是又开始了狂看书的路程。

c++ 之父Bjarne Stroustrup 的《The Design

and

相关文档
最新文档