设计模式原则总结

- - IT技术博客大学习

0、单一职责原则（SRP）就一个类而言，应该仅有一个引起它变化的原因. 一、”开放－封闭”原则(OCP) 在软件设计模式中，这种不能修改，但可以扩展的思想也是最重要的一种设计原则. 即软件实体（类、模板、函数等等）应该可以扩展，但是不可修改. 【通俗】：设计的时候，时刻考虑，尽量让这个类是足够好，写好了就不要去修改了，如果新需求来，我们增加一些类就完事了，原来的代码能不动则不动.

26.1 设计模式和设计原则. 26.1.1 设计模式和设计原则的关系. 面向对象的分析设计有很多原则，这些原则大都从思想层面，给我们指出了面向对象分析设计的正确方向，是我们进行面向对象分析设计应该尽力遵守的准则. 而设计模式已经是针对某个场景下某些问题的某个解决方案. 也就是说这些设计原则是思想上的指导，而设计模式是实现上的手段，因此设计模式也是应该遵守这些原则的，换句话说，设计模式就是这些设计原则的一些具体体现.

【设计模式系列】之六大原则

- - CSDN博客推荐文章

一、单一职责原则（Single Responsibility Principle） . 定义：一个类仅有一个引起它变化的原因. 解析：单一职责是针对类的方法而言，职责单一不等于就一个方法，而指的是一种类型的方法. 举个例子：OnlineRecord类的单一职责体现在，其方法都是关于“上机记录”的，如：增加上机记录、查询上机记录、删除上机记录、修改上机记录.

Scala设计模式

- - ITeye博客

我的话：在国外网站上看到一篇文章，里面详细描述了很多设计模式，并且用Java及Scala两种语言描述，清晰的让我们看到各种常规的设计模式，在Scala中是如何在语言特性层面直接支持的. 基于文章很nice，我利用今天的空闲时间将其翻译，希望大家能一起学习，讨论. 翻译比较倡促，也就两小时左右，有何不当，请在下面留言指出.

Spring设计模式

- - 行业应用 - ITeye博客

springMVC通常采用属性注入的IOC方式和AOP织入方式相结合实现依赖注入同时使用强制代理方式，代理类或者接口. 这里又涉及到单例模式（注入的类或者接口在容器中只存在一个）、工厂模式（通过反射实现类实例化过程的公用化）、楼上所说的装饰模式属于AOP织入的一部分. 想了解spring先从IOC和AOP开始吧.

“另类” 设计模式

- Sean Lee - 酷壳 - CoolShell.cn

下面这篇文章来自这里：http://www.lsd.ic.unicamp.br/~oliva/fun/prog/resign-patterns，这篇文章有点意思了，山寨了我们著名的Design Pattern. 这篇文章并不是很容易翻译，也许我翻译的不好，大家多指正. 另外，这篇文章将失去原有的趣味在于其使用了经典设计模式的单词很相似的单词，一走眼你还以为是正二八经的设计模式.

【译】屏幕设计模式

- 志强 - 所有文章 - UCD大社区

模式是广泛适用的解决一般问题的解决方案. 在开发应用程序过程中，无论是面对抽象还是实际问题，模式都大有用处. 而标准屏幕模式对于优秀的Web程序甚至企业级软件都很有帮助. 摘要/细节（Master/Detail）. 摘要/细节模式可横向也可竖向. 该模式是满足用户既停留在一个页面又可浏览多个条目需求的典范.

设计模式之代理模式（Proxy）

- - 博客园_首页

这段时间一直忙于期末考试，好久没来博客园了，现在好了，终于考完了，也该过上正常的日子了. 开学就是大四的学生了，时间过的可是真快啊，转眼间大学四年已经接近尾声了. 回想大学这三年，成绩还可以吧（年级前10%），参加过各种竞赛（acm，数学建模等等），学生会也呆过（打了一年的酱油），好哥们也有那么五六个（希望以后能在一个城市发展，大学期间的宝贵财富啊），另外所谓的大学生创新实践项目也搞了一个（就算开阔一下视野吧，大学能生有什么创新呢.

Web应用的缓存设计模式

- - robbin的自言自语

从10年前的2003年开始，在Web应用领域，ORM(对象-关系映射)框架就开始逐渐普及，并且流行开来，其中最广为人知的就是Java的开源ORM框架Hibernate，后来Hibernate也成为了EJB3的实现框架；2005年以后，ORM开始普及到其他编程语言领域，其中最有名气的是Ruby on rails框架的ORM － ActiveRecord.

面向对象设计模式的核心法则

- tonytech - Michael`s blog

有本经典的书叫《设计模式》，讲了经典的21种设计模式，建议大家都看看. 就一个类而言，应该仅有一个引起它变化的原因. 如果一个类承担的职责过多，就等于把这些职责耦合在一起，一个职责的变化可能会削弱或者抑制这个类完成其他职责的能力. 这种耦合会导致脆弱的设计，当变化发生时，设计会遭到意想不到的破坏. 软件设计真正要做的许多内容，就是发现职责并把那些职责互相分离.

名称	解释
0、单一职责原则（SRP）	就一个类而言，应该仅有一个引起它变化的原因。
一、”开放－封闭”原则(OCP)	在软件设计模式中，这种不能修改，但可以扩展的思想也是最重要的一种设计原则。即软件实体（类、模板、函数等等）应该可以扩展，但是不可修改。【通俗】：设计的时候，时刻考虑，尽量让这个类是足够好，写好了就不要去修改了，如果新需求来，我们增加一些类就完事了，原来的代码能不动则不动。
二、里氏代换原则（LSP）	1.一个软件实体如果使用的是一个父类的话，那么一定适用于该子类，而且他觉察不出父类对象和子类对象的区别。也就是说，在软件里面，把父类都替换成它的子类，程序的行为没有变化。【一句话】：子类型必须能够替换掉他们的父类型。
三、依赖倒置原则(DIP)	1.高层模块不应该依赖于底层模块。两个都应该依赖抽象。2.抽象不应该依赖于细节，细节依赖于抽象（【白话】：针对接口编程，不要针对实现编程。
四、接口隔离原则（ISP）	1.使用多个专门的接口比使用单一的总接口总要好。换而言之，从一个客户类的角度来讲：一个类对另外一个类的依赖性应当是建立在最小接口上的。 2．过于臃肿的接口是对接口的污染。不应该强迫客户依赖于它们不用的方法。
五、合成/聚合复用原则（CARP）	尽量使用合成/聚合，尽量不要使用类继承。【聚合】：表示一种弱的拥有关系，体现的是A对象可以包含B对象，但B对象不是A对象的一部分。【合成】：一种强的拥有关系，提现了严格的部分和整体的关系，部分和整体的生存周期一致。
六、迪米特法则（LoD）最少知识原则	强调类之间的松耦合。即：如果两个类不必彼此直接通信，那么着两个类就不应当发送直接的相互作用。如果其中一个类需要调用另一个类的某一个方法的话，可以通过第三者转发这个调用。

设计模式原则总结

相关 [设计模式原则] 推荐：