- 浏览: 1704911 次
- 性别:
- 来自: 杭州699号
文章分类
最新评论
-
莫莫摸:
为什么不用dubbo
RCP数据传输模型回顾 -
大胡子爸爸:
String, Class 都实现了Serializable接 ...
RPC框架几行代码就够了 -
lss598018587:
谢谢大神分享,比起新手看复杂的dubbo框架还不如看大神的这一 ...
RPC框架几行代码就够了 -
15606915740:
你好,请问一下。<dubbo:consumer filt ...
Dubbo文档 -
joqk12345:
...
一些设计上的基本常识
每个程序员都应牢记的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(访问者模式)
全称怎么写啊??
我英语太烂了 :'(
全称是:Keep it Simple, Stupid
我英语也很烂,这里高手不少,希望还有的救。
跟据场景套模式。模式对应的是问题的场景,是一种抽象层次更高的编程。对于多数问题,能够KISS是最好的,不用为了模式而模式。
赞同你的观点,KISS是Practical的真理,利用模式,而不是被模式利用!
跟据场景套模式。模式对应的是问题的场景,是一种抽象层次更高的编程。对于多数问题,能够KISS是最好的,不用为了模式而模式。
(一)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(访问者模式)
评论
9 楼
javatar
2006-12-28
fins 写道
全称怎么写啊??
我英语太烂了 :'(
全称是:Keep it Simple, Stupid
我英语也很烂,这里高手不少,希望还有的救。
Godlikeme 写道
跟据场景套模式。模式对应的是问题的场景,是一种抽象层次更高的编程。对于多数问题,能够KISS是最好的,不用为了模式而模式。
赞同你的观点,KISS是Practical的真理,利用模式,而不是被模式利用!
8 楼
Godlikeme
2006-12-28
fins 写道
全称怎么写啊??
我英语太烂了 :'(
keep it simple, stupid.我英语太烂了 :'(
7 楼
fins
2006-12-28
全称怎么写啊??
我英语太烂了 :'(
我英语太烂了 :'(
6 楼
抛出异常的爱
2006-12-28
保持简单,傻瓜
5 楼
fins
2006-12-28
"能够KISS是最好的" kiss什么意思啊?? 呵呵 见笑了
4 楼
Godlikeme
2006-12-28
fins 写道
javatar似乎一直都很重视模式
从他的代码中就能看出来 呵呵
我就不行了 那些东西记不住
虽然偶尔会在不经意间用到一些 但是你要问我 我用了什么模式 为什么用 这么用有什么好处 我肯定答不上来 呵呵
设计模式的书当初也没少看 重构也看过
可是...
都是机械化的开发流程害的 我们在开发中几乎没有机会接触模式
原因有2 1是现在流行的各种框架本身已经包含了各种模式 在使用他们的时候往往感觉不到模式的存在(除了di)
2是我们的开发规范比较成型 分工的粒度比较细致
所以不管是 action 也好 bo 也好 dao也好
几乎都是一些方法的堆砌 ctrl+c ctrl+v再改改 配制文件里配配 几乎就没什么了
现在的结果就是
学了一堆模式 工作中用不上
于是渐渐的忘记了该如何用
再于是 在能用上模式的时候 也不会用
越不会用越不用 越不用越不会用
如此恶性循环下去
我想很多人都应该有我这样的困惑吧
郁闷...
从他的代码中就能看出来 呵呵
我就不行了 那些东西记不住
虽然偶尔会在不经意间用到一些 但是你要问我 我用了什么模式 为什么用 这么用有什么好处 我肯定答不上来 呵呵
设计模式的书当初也没少看 重构也看过
可是...
都是机械化的开发流程害的 我们在开发中几乎没有机会接触模式
原因有2 1是现在流行的各种框架本身已经包含了各种模式 在使用他们的时候往往感觉不到模式的存在(除了di)
2是我们的开发规范比较成型 分工的粒度比较细致
所以不管是 action 也好 bo 也好 dao也好
几乎都是一些方法的堆砌 ctrl+c ctrl+v再改改 配制文件里配配 几乎就没什么了
现在的结果就是
学了一堆模式 工作中用不上
于是渐渐的忘记了该如何用
再于是 在能用上模式的时候 也不会用
越不会用越不用 越不用越不会用
如此恶性循环下去
我想很多人都应该有我这样的困惑吧
郁闷...
跟据场景套模式。模式对应的是问题的场景,是一种抽象层次更高的编程。对于多数问题,能够KISS是最好的,不用为了模式而模式。
3 楼
jin.libing
2006-12-28
还不太是太理解程序员的生活。刚出来。。。。。
2 楼
fins
2006-12-28
javatar似乎一直都很重视模式
从他的代码中就能看出来 呵呵
我就不行了 那些东西记不住
虽然偶尔会在不经意间用到一些 但是你要问我 我用了什么模式 为什么用 这么用有什么好处 我肯定答不上来 呵呵
设计模式的书当初也没少看 重构也看过
可是...
都是机械化的开发流程害的 我们在开发中几乎没有机会接触模式
原因有2 1是现在流行的各种框架本身已经包含了各种模式 在使用他们的时候往往感觉不到模式的存在(除了di)
2是我们的开发规范比较成型 分工的粒度比较细致
所以不管是 action 也好 bo 也好 dao也好
几乎都是一些方法的堆砌 ctrl+c ctrl+v再改改 配制文件里配配 几乎就没什么了
现在的结果就是
学了一堆模式 工作中用不上
于是渐渐的忘记了该如何用
再于是 在能用上模式的时候 也不会用
越不会用越不用 越不用越不会用
如此恶性循环下去
我想很多人都应该有我这样的困惑吧
郁闷...
从他的代码中就能看出来 呵呵
我就不行了 那些东西记不住
虽然偶尔会在不经意间用到一些 但是你要问我 我用了什么模式 为什么用 这么用有什么好处 我肯定答不上来 呵呵
设计模式的书当初也没少看 重构也看过
可是...
都是机械化的开发流程害的 我们在开发中几乎没有机会接触模式
原因有2 1是现在流行的各种框架本身已经包含了各种模式 在使用他们的时候往往感觉不到模式的存在(除了di)
2是我们的开发规范比较成型 分工的粒度比较细致
所以不管是 action 也好 bo 也好 dao也好
几乎都是一些方法的堆砌 ctrl+c ctrl+v再改改 配制文件里配配 几乎就没什么了
现在的结果就是
学了一堆模式 工作中用不上
于是渐渐的忘记了该如何用
再于是 在能用上模式的时候 也不会用
越不会用越不用 越不用越不会用
如此恶性循环下去
我想很多人都应该有我这样的困惑吧
郁闷...
1 楼
凤舞凰扬
2006-12-28
记是没有用的,更重要的是要理解它,这种理解不仅仅是理解它怎么样,更多的是理解为什么要这么用,它的好处和缺点何在。
发表评论
-
能力成长模型
2012-05-09 00:28 23017最近看了温伯格1986年出版的《技术领导之路》, 很老的书,讲 ... -
以HTTL为例讲讲模块分包&领域模型&扩展框架
2011-10-09 20:08 16816注:该博客内容已加入 ... -
使用Map参数的Webx3扩展
2011-08-28 02:10 5935因Webx3是开源的,所以把这个简单的Webx3扩展发在博客上 ... -
Netty内存泄露
2011-08-02 20:09 24980转于自己在公司的Blog: ... -
Grizzly和Netty以及Mina简单性能对比
2011-07-17 02:48 29767转于自己在公司的Blog: http://pt.alibaba ... -
RPC框架几行代码就够了
2011-07-14 00:34 90294转于自己在公司的Blog: http://pt.alibaba ... -
魔鬼在细节中
2011-05-24 14:50 32255转于自己在公司的Blog: ... -
Dubbo扩展点重构
2011-05-12 22:09 38913转于自己在公司的Blog: http://pt.alibaba ... -
配置设计
2011-03-09 23:41 23615转于自己在公司的Blog: ... -
[转]HTML5设计原理
2011-03-09 22:57 7841Jeremy Keith在 Fronteers 2010 ... -
Hessian序列化不设SerializerFactory性能问题
2010-12-27 11:38 6490转于自己在公司的Blog: http://pt.alibaba ... -
动态代理方案性能对比
2010-11-17 21:38 46258转于自己在公司的Blog: http://pt.alibaba ... -
防痴呆设计
2010-11-05 18:58 17704转于自己在公司的Blog: ... -
负载均衡扩展接口重构
2010-11-05 18:53 8768转于自己在公司的Blog: ... -
分布式服务框架常被质疑的价值
2010-11-05 18:52 5743转于自己在公司的Blog: http://pt.alibaba ... -
Hessian3.2.1在序列化32.5k字符串时的问题
2010-11-05 18:49 7289转于自己在公司的Blog: http://pt.alibaba ... -
一些设计上的基本常识
2010-07-05 19:28 27806转于自己在公司的Blog: ... -
谈谈扩充式扩展与增量式扩展
2010-06-12 19:46 19428转于自己在公司的Blog: http://pt.alibaba ... -
Scaling Architecture
2010-02-25 10:31 4130Scaling Second Life: http://p ... -
EBay SOA
2010-02-23 18:23 4812EBay SOA PPT
相关推荐
国外程序员推荐:每个程序员都应读的书 ,开发设计人员必备
每个程序员都会的35种小技巧,干货推荐,每个程序员都会的35个jQuery小技巧!
【标题】:“每个程序员都应该看看的” 【描述】:“适合于每个做程序开发的人,特别是刚开始学程序的!更应该好好看看!”这句话暗示了这份资料是面向初学者和程序员的通用指南,它可能包含了编程基础知识、最佳...
哪本书是对程序员最有影响、每个程序员都该阅读的书? 国外知名网站stackoverflow上有一个问题调查: 哪本书是对程序员最有影响、每个程序员都该阅读的书?,这个调查已历时两年,目前为止吸引了153,432人访问,读者...
"程序员必备的7种武器"概括了程序员在工作中最常使用且至关重要的技能,下面将对这些武器进行深入解析。 1. **正则表达式(Regular Expressions)**:正则表达式是一种强大的文本处理工具,用于匹配、查找、替换或...
接下来,我们就来深入探讨为什么设计模式是每个程序员都需要学习并掌握的知识。 首先,设计模式在技术面试中的重要性不容小觑。面试官通常会通过考察应聘者对设计模式的理解和应用能力来判断其编程基础和软件设计...
【博客绑定技术文档】每个程序员都该有个自己的博客,分享我的四种博客搭建教程!
在IT行业中,程序设计思想是每个程序员不可或缺的技能,它涉及到如何有效地解决问题、编写可维护的代码以及优化软件设计。本压缩包中的书籍资源恰好涵盖了这个主题的重要方面,旨在帮助程序员提升自己的编程素养。 ...
如果您是一个初级的 coder,可以从中领会到怎么设计一段优秀的代码;如果您是一个高级程序员,可以从中全面了解到设计模式以及 Java 的边角技术的使用;如果您是一个顶级的系统分析师,可以从中获得共鸣!
以下是对程序员应具备的12种能力的详细解析: 1. **编程语言能力**:精通一门编程语言是程序员的基础,这意味着深入理解语法、特性以及如何高效地解决问题。这需要时间和实践的积累,而不仅仅是速成课程。 2. **...
《java23种设计模式详细讲解》这本书系统地介绍了23种设计模式,并通过具体的例子来阐释每种模式的应用场景和实现方式,旨在帮助程序员提升设计能力,编写更优雅、可维护的代码。书中的内容涵盖了创建型模式、结构型...
模式编程是一种将常见问题的解决方案抽象化、模板化的方法,旨在提高代码的可读性、可维护性和重用性。这种编程方式可以帮助程序员在面对复杂系统设计时,借鉴已有的成功经验,避免重复发明轮子,从而提升开发效率。...
600个程序员常用的单词和词汇600个程序员常用的单词和词汇600个程序员常用的单词和词汇600个程序员常用的单词和词汇600个程序员常用的单词和词汇600个程序员常用的单词和词汇600个程序员常用的单词和词汇600个程序员...
1. **审慎行事(Act with Prudence)**:在编程工作中,审慎行事意味着对待每一行代码和每一个决策都要三思而后行。Seb Rose提出了这一点,强调在采取行动之前仔细考虑可能的后果。 2. **应用函数式编程原则(Apply...
—合格程序员应该具备的12种能力" 指向了一个讨论合格程序员所需技能的主题。在这个行业中,成为一个优秀的程序员不仅仅是掌握编程语言那么简单,还需要一系列综合能力。以下是对这些能力的详细阐述: 1. **解决...
24种设计模式介绍与6大设计原则希望这本书的阅读者具备最基本的代码编写能力,您是一个初级的 coder,可以从中领会到怎么设计 一段优秀的代码;您是一个高级程序员,可以从中全面了解到设计模式以及 Java 的边角技术...
作为程序员,掌握这两种语言不仅是提升个人技术能力的必经之路,更是深入理解计算机科学原理的重要基础。 C语言的历史悠久,它的设计哲学强调简洁性、灵活性和高效的执行速度。这种语言具有接近硬件的操作能力,使...
1. **设计原则与模式**:书中可能会介绍如单一职责原则(SRP)、开闭原则(OCP)、里氏替换原则(LSP)、接口隔离原则(ISP)、依赖倒置原则(DIP)等面向对象设计的基本原则,以及工厂模式、单例模式、观察者模式等经典设计...