每个程序员都应牢记的7种坏味道,11种原则,23种模式

(一)7种设计坏味道
1.僵化性: 很难对系统进行改动,因为每个改动都会迫使许多对系统其他部分的其它改动。

2.脆弱性: 对系统的改动会导致系统中和改动的地方在概念上无关的许多地方出现问题。

3.牢固性: 很难解开系统的纠结,使之成为一些可在其他系统中重用的组件。

4.粘滞性: 做正确的事情比做错误的事情要困难。

5.复杂性(不必要的): 设计中包含有不具任何直接好处的基础结构。

6.重复性(不必要的): 设计中包含有重复的结构,而该重复的结构本可以使用单一的抽象进行统一。

7.晦涩性: 很难阅读、理解。没有很好地表现出意图。

(二)11种原则 - Principle

----类原则

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

就一个类而言,应该仅有一个引起它变化的原因。

(职责即为“变化的原因”。)

2.开放-封闭原则 - Open Close Principle(OCP)

软件实体(类、模块、函数等)应该是可以扩展的,但是不可修改。

(对于扩展是开放的,对于更改是封闭的.

关键是抽象.将一个功能的通用部分和实现细节部分清晰的分离开来.

开发人员应该仅仅对程序中呈现出频繁变化的那些部分作出抽象.

拒绝不成熟的抽象和抽象本身一样重要. )

3.里氏替换原则 - Liskov Substitution Principle(LSP)

子类型(subclass)必须能够替换掉它们的基类型(superclass)。

4.依赖倒置原则(IoCP) 或 依赖注入原则 - Dependence Inversion Principle(DIP)

抽象不应该依赖于细节。细节应该依赖于抽象。

(Hollywood原则: "Don‘t call us, we‘ll call you".

程序中所有的依赖关系都应该终止于抽象类和接口。

针对接口而非实现编程。

任何变量都不应该持有一个指向具体类的指针或引用。

任何类都不应该从具体类派生。

任何方法都不应该覆写他的任何基类中的已经实现了的方法。)

5.接口隔离原则(ISP)

不应该强迫客户依赖于它们不用的方法。

接口属于客户,不属于它所在的类层次结构。

(多个面向特定用户的接口胜于一个通用接口。)

----包内聚原则

6.重用发布等价原则(REP)

重用的粒度就是发布的粒度。

7.共同封闭原则(CCP)

包中的所有类对于同一类性质的变化应该是共同封闭的。

一个变化若对一个包产生影响,

则将对该包中的所有类产生影响,

而对于其他的包不造成任何影响。

8.共同重用原则(CRP)

一个包中的所有类应该是共同重用的。

如果重用了包中的一个类,

那么就要重用包中的所有类。

(相互之间没有紧密联系的类不应该在同一个包中。)

----包耦合原则

9.无环依赖原则(ADP)

在包的依赖关系图中不允许存在环。

10.稳定依赖原则(SDP)

朝着稳定的方向进行依赖。

应该把封装系统高层设计的软件(比如抽象类)放进稳定的包中,

不稳定的包中应该只包含那些很可能会改变的软件(比如具体类)。

11.稳定抽象原则(SAP)

包的抽象程度应该和其稳定程度一致。

(一个稳定的包应该也是抽象的,一个不稳定的包应该是抽象的. )

----其它扩展原则----

12.BBP(Black Box Principle)黑盒原则

多用类的聚合,少用类的继承。

13.DAP(Default Abstraction Principle)缺省抽象原则

在接口和实现接口的类之间引入一个抽象类,这个类实现了接口的大部分操作.

14.IDP(Interface Design Principle)接口设计原则

规划一个接口而不是实现一个接口。

15.DCSP(Don‘t Concrete Supperclass Principle)不要构造具体的超类原则

避免维护具体的超类。

16.迪米特法则

一个类只依赖其触手可得的类。

(三)23种设计模式 - Pattern.

创建型

Abstract Factory(抽象工厂模式) -> (简单工厂模式)

Factory Method(工厂模式)

Builder(生成器模式)

Singleton(单件模式) -> (多例模式)

Prototype(原型模式)

结构型

Adapter(适配器模式)

Bridge(桥接模式)

Composite(组合模式)

Decorator(装饰模式)

Facade(外观模式,门面模式)

Flyweight(享元模式) -> (不变模式)

Proxy(代理模式)

行为型

Chain of Responsibility(职责链模式)

Command(命令模式)

Interpreter(解释器模式)

Iteartor(迭代器模式)

Mediator(中介者模式)

Memento(备忘录模式)

Observer(观察者模式)

State(状态模式)

Strategy(策略模式)

TemplateMethod(模板方法模式)

Visitor(访问者模式)

每个程序员都应牢记的7种坏味道,11种原则,23种模式

时间: 2024-10-09 23:34:48

每个程序员都应牢记的7种坏味道,11种原则,23种模式的相关文章

每个程序员都应读的书(转)

收藏,有时间,就读一读,有好处! 很多程序员响应,他们在推荐时也写下自己的评语.以前就有国内网友介绍这个程序员书单,不过都是推荐数 Top 10的书.其实除了前10本之外,推荐数前30左右的书籍都算经典,伯乐在线整理编译这个问答贴,同时摘译部分推荐人的评语.下面就按照各本书的推荐数排列. 1. <代码大全> 史蒂夫·迈克康奈尔 推荐数:1684 “优秀的编程实践的百科全书,<代码大全>注重个人技术,其中所有东西加起来,就是我们本能所说的“编写整洁的代码”.这本书有50页在谈论代码布

程序员都应学习代码编译器知识

程序员都应学习代码编译器知识   所有优秀的计算机科学学院都提供了编译器课程,但是相对比较少的学校把它作为本科课程的必修部分.这篇文章回答了这个问题:为什么需要学习编译器知识?即使你从没打算过编写编译器. 我写这篇文章的其中一个原因是,尽管我在读本科时很喜欢编译器课程,但是我几乎看不到它的实际作用.大多数资料看起来要么简单易懂,要么很深奥(事实上,我找到的大部分编译器资料都是很枯燥的.)无论怎样,我用了几年时间总结了为什么这类课程会如此有用的实际原因.原因如下. 分析器和解析器无处不在 严谨的p

StackOverflow程序员推荐:每个程序员都应读的30本书

“如果能时光倒流,回到过去,作为一个开发人员,你可以告诉自己在职业生涯初期应该读一本,你会选择哪本书呢?我希望这个书单列表内容丰富,可以涵盖很多东西.” 很多程序员响应,他们在推荐时也写下自己的评语.以前就有国内网友介绍这个程序员书单,不过都是推荐数 Top 10的书.其实除了前10本之外,推荐数前30左右的书籍都算经典,伯乐在线整理编译这个问答贴,同时摘译部分推荐人的评语.下面就按照各本书的推荐数排列. 1. <代码大全>史蒂夫·迈克康奈尔 推荐数:1684 “优秀的编程实践的百科全书,&l

国外程序员推荐:每个程序员都应读的书

[更新]:近日(2012年8月17日)重看 StackOverflow 的原讨论帖,发现于今年年初被关闭了.不过有人做了汇总,把其他回复中提到的书籍,放在投票数最高的回复中.新更新添加 59 本书,详情可见文章后半部分. 编者按:2008年8月4日,StackOverflow 网友 Bert F 发帖提问:哪本最具影响力的书,是每个程序员都应该读的? “如果能时光倒流,回到过去,作为一个开发人员,你可以告诉自己在职业生涯初期应该读一本,你会选择哪本书呢?我希望这个书单列表内容丰富,可以涵盖很多东

每一个程序员都必须阅读的10篇文章

原文:10 Atricle Every Programmer Must Read by Javin Paul 作为一名Java程序员和软件开发者,我已经从那些名为<关于XXX,每个程序员都应了解的>的文章中学了很多东西,这些文章倾向于提供许多关于某一个特定主题的实用的.有深度.难以发掘的信息.在我的学习过程中,我读到了不少非常有用的文章,我会收藏这些文章以便日后参考和再次阅读.我个人认为所有程序员可以从这些文章中获益,这也是促使我发帖,并与你们分享这些<关于XXX,每个程序员都应了解的&

每个程序员都应该了解的 CPU 高速缓存

每个程序员都应该了解的 CPU 高速缓存 英文原文:Memory part 2: CPU caches 来源:oschina [编者按:这是Ulrich Drepper写“程序员都该知道存储器”的第二部.那些没有读过第一部 的读者可能希望从这一部开始.这本书写的非常好,并且感谢Ulrich授权我们出版. 一点说明:书籍出版时可能会有一些印刷错误,如果你发现,并且想让它在后续的出版中更正,请将意见发邮件到[email protected] ,我们一定会更正,并反馈给Ulrich的文档副本,别的读者

每个程序员都可能犯过的10个错误

本文列出的10个错误,并不局限于C#.Java.Delphi.JavaScript等——几乎涵盖了所有的编程语言.是不是大吹大擂,欢迎各位品鉴…… 1.面向编译器写代码,而不是面向用户 当人们使用编译器创建自己的App时,在把自己的想法诉诸于机器代码的过程中,常常会将那些可以使得编程更为简单却又冗长的语法遗忘于脑后.无论你使用的是单字母的标识符还是更易于人脑理解的标识符,对于编译器而言,毫无区别.编译器不在乎你写的是否是优化表达式,也不在乎你是否用括号封装了子表达式.编译器要做的就是将这些人脑可

每个程序员都应该了解的内存知识

每个程序员都应该了解的内存知识 英文原文:lwn.net,翻译:开源中国 [编辑的话: Ulrich Drepper最近问我们,是不是有兴趣发表一篇他写的内存方面的长文.我们不用看太多就已经知道,LWN的读者们会喜欢这篇文章的.内存的使用常常是软件性能的决定性因子,而如何避免内存瓶颈的好文章却不好找.这篇文章应该会有所帮助. 他的原文很长,超过100页.我们把它分成了7篇,每隔一到两周发表一篇.7篇发完后,Ulrich会把全文发出来. 对原文重新格式化是个很有挑战性的工作,但愿结果会不错吧.为了

[注]十大编程禁忌 -- 程序员都必须克服

程序员在编程的时候难免会犯错误,但如果不从错误中吸取教训,那么习惯成自然,你会经常犯错的.从错误中不断的学习,锻炼好的行为习惯有助于事业上的稳定. 这就是我们如何将小麦从糟糠中区别出来以及如何避免编程禁忌的绝佳经验.此外,最重要的就是可以为客户带来更好的用户体验. 1. 不提升非技术技能 我们认为非技术技能是项目成功的主要因素.这些非技术技能也可以称之为“软技能”,总体上来说,它已经被公司证明为能够驾驭企业和客户之间的长期商业关系,因此也能决定公司的成长发展路径.一些关键的软技能指标包括: a.