设计模式的学习

OOP的核心思想:

 

封装(Encapsulation).

继承(inheritance).

多态(polymorphism).

 

什么是类?

概念层某些责任的抽象.

规格层一系列可以被其他对象使用的接口.

语言层封装了代码和数据.

 

 

软件设计原则:

针对接口编程,而不是针对实现.

不要滥用继承,理清继承和组合的关系.

[继承处理类之间的静态关系,组合处理对象间的动态关系]

分清层次,封装变化点.

 

类设计原则:

 

单一职责原则(SRP-Single Responsibility Principle).

一个类应该只有一个引起它变化的原因.

[如果一个类既负责一个类的显示,又表示一个类的存储,当显示需求变化时或者存储变化时都要修改这同一个类. 不过, 虽然SRP要求对每一个可能变化的职责都进行分开固然是正确的,但是这个变化一定要是现实中“真的可能”发生的。我们要专注于那些有较大可能发生变化的地方,而忽略那些不太可能变化或变化概率极小的细枝末节。比如说,你的数据访问逻辑是固定的,而中途变化数据库的可能也不大,因此,就没有必要把数据访问单独出来。一句话,不能为了“Everything is possible”,就把类结构设计的异常复杂。]

 

开放封闭原则(OCP-The Open-Closed Principle).

类可以扩展,但不可修改(对扩展开放,对修改封闭)[继承,让模块依赖于一个固定的抽象体,这个抽象体是不可以修改的;同时,通过这个抽象体派生,我们就可以扩展此模块的行为功能.关键是对抽象体的定义.]

 

Liskow替换原则(LSP -Liskov Substitution Principle)

子类必须可以替换基类.

[子类必须能够完成父类定义的所有任务]

 

依赖倒置原则(DIP-Dependency-Inversion Principles).

高层模块不应该依赖低层模块,二者应该依赖于抽象.

抽象不应该依赖于实现,实现应该依赖于抽象.

 

接口隔离原则(ISP-Interface Segregation Principle ).

不应该强迫客户程序依赖于它们不用的方法,一个类对另外一个类的依赖性应当是建立在最小的接口上(不要把不相关的放在同一个接口中).

 

 

什么是设计模式

描述软件设计过程中某一类常见问题的一般性解决方案.

 模式是用来对应变化的,不要为了用模式而用模式.

 

模式分类:

创建型(creational):负责对象创建.

结构型(structural): 处理类于对象的组合.

行为型(behavioral).:类于对象交互中的职责分配.

如何学好c语言

转载coolshell,关于学习成长。

keep_walker :
今天晚上我看到这篇文章。
http://programmers.stackexchange.com/questions/62502/small-c-projects

我也遇到了和提问的老外一样的问题。。能给像遇到这样烦恼的程序员一点建议嘛?谢谢!

我相信,这可能是很多朋友的问题,我以前也有这样的感觉,编程编到一定的时候,发现能力到了瓶颈,既不深,也不扎实,半吊子。比如:你长期地使用Java和.NET ,这些有虚拟机的语言对于开发便利是便利,但是对于程序员来说可能并不太好,原因有两个:

虚拟机屏蔽了操作系统的系统调用,以及很多底层机制。
大量的封装好的类库也屏蔽了很多实现细节。
一段时间后,你会发现你知其然,不知所以然。。我以前在CSDN上写过一篇《Java NIO类库Selector机制解析(上,下,续)》,在那篇文章中我说提到过(有讥讽的语气)Java的程序员不懂底层实现,所以很难把技术学得更扎实。此时,一部分程序员会不自然地想学学底层的技术,很自然的,C语言就被提了上来。

下面是我给这位朋友的一些建议:
鼓励并为你叫好。我鼓励你想要去学C语言的想法和精神,很多人都觉得C语言好学,其实并不然。(你可以看看《C语言的迷题》)现在的这个社会更多地去关注那些时髦的技术,而忽略了这个流行了40+年的C语言。一门技术如果能够流行40多年,这才是你需要去关注和学习的技术,而不是那些刚出来的技术(过度炒作的技术,Windows编程史)。这才是踏踏实实的精神。
不要找借口。这一条路走下来并不容易,不要给自己找借口。我最不喜欢听到的就是“很忙,没有时间”这样的借口。我以前在银行做项目,早9点到晚10点,周一到周六,我一样可以每天抽1个小时来看书和专研,一年下来也能精读5、6本书。我现在的工作项目和招聘任务很紧张,刚生的小孩只有自己和老婆两人带,还需要准备讲课,但是我还是能够找到时间看文章写文章维护酷壳。所以,我可以告诉你,“时间就像乳沟,只要你肯挤,就一定会有”。
学好C语言和系统编程。我认为,学好编程有四个方面:语言、算法和数据结构、系统调用和设计。
语言。我可以告诉你C语言有两大主题你要好好学,一个是内存管理,一个是指针!这个世界上90%以上的C/C++出的严重性错误全是和这两个有关。不要看谭浩强的那本书,那本是本烂书。推荐这本书给你《C程序设计语言(第2版·新版)》
算法和数据结构。我认为,用C语言实现算法和数据结构莫过于最爽的事情。推荐你看这本书——算法:C语言实现(第1~4部分)基础知识、数据结构、排序及搜索(原书第3版),还有那本经典的《算法导论》
系统编程。Windows下推荐两本书——《Windows 程序设计 》和《Windows核心编程》,Unix/Linux下推荐两本书——《Unix高级环境编程》和《Unix网络编程卷1,套接字》《Unix网络编程卷2,进程间通信》尤其是《Unix网络编程》这本书,一通百通,无论Windows还是Unix/Linux,都是一样的。
系统设计。关于设计方面,我全力推荐《Unix编程艺术》,看完以后,你就明白什么是真正的编程文化了。然后,当你看到Windows的Fans的某些言论时,你就知道什么叫一笑了之了。
如果你能在2-3年内精读完这些书,并全部融会贯通,那么你就明白什么是一览众山小的感觉了!我足足花了5年时间才算是真正全部读完这些书的。最后,祝你好运!努力!

我想,这篇文章主要想告诉大家这么几件事:

编程编到一定时候,你就需要了解底层系统的机制,否则,知其然不知所以然。
我没有否定非C的程序员的逻辑,真正的逻辑是——如果你想要了解底层机制,请学习C语言和操作系统。
40多年的Unix/C影响深远。包括影响了Windows。如果你想一通百通,一定要了解Unix。那是计算机文化真正的根。
不要肤浅地去思考问题。比如,不要以为一个DBA就不会考虑数据库引擎的内存页面的问题。也不要以为Web程序员就不需要了解后台的服务器和脚本的运行性能以及TCP/IP的问题。
高手往往都是有很强的系统的基础知识的,表面的东西永远是肤浅的.