用户操作
[留言]  [发消息]  [加为好友] 
订阅我的博客
XML聚合    FeedSky
订阅到鲜果
订阅到Google
订阅到抓虾
rgbwoo的公告
<a href="http://www3.clustrmaps.com/counter/maps.php?url=http://blog.csdn.net/rgbwoo" id="clustrMapsLink"><img src="http://www3.clustrmaps.com/counter/index2.php?url=http://blog.csdn.net/rgbwoo" style="border:0px;" alt="Locations of visitors to this page" title="Locations of visitors to this page" id="clustrMapsImg" onError="this.onError=null; this.src='http://www2.clustrmaps.com/images/clustrmaps-back-soon.jpg'; document.getElementById('clustrMapsLink').href='http://www2.clustrmaps.com'" /> </a><br> <img src="http://services.nexodyne.com/email/icon/77Qq94Sk/OYPjkto%3D/R01haWw%3D/0/image.png"/><br> <img src="http://services.nexodyne.com/email/icon/d%2BhIE9wNEA%3D%3D/ynF1NV8%3D/SG90bWFpbA%3D%3D/0/image.png"/><br> <img src="http://services.nexodyne.com/email/customicon/UFrGeA2U17613wXDswQ%3D/EjcmNuM%3D/000000/bfbfff/000000/1/image.png"/>
文章分类
struts链接
StrutsTest使用简明手册
论坛
Hibernate中文论坛
Spring中文论坛
相关网站
Hibernate
Spring
存档

原创  OOA/D学习笔记(2) 收藏

 
OOD的原则
良好的设计，就是系统容易理解、容易改变、容易重用。

设计的“异味”
  1. 僵化性（Rigidity）——系统很难改变，因为改动一处，就不得不改动其他地方，甚至引起无休止的连锁反应
  2. 易碎性（Fragility）——改变某个部分，会破坏很多完全无关的部分
  3. 固化性（Immobility）——很难将系统分解成可供其他系统重用的组件
  4. 粘稠性（Viscosity）——永远走不出编辑-编译-测试这一无休止的循环
  5. 不必要的复杂性（Needless Complexity）——很多非常聪明的代码结构目前还不需要，但有一天可能用上
  6. 不必要的重复性（Needless Repetition）——代码看上去是两个叫剪切和粘贴的程序员写的
  7. 不透明性（Opacity）——
UML图可以帮助我们，通过检查图之间的依赖关系，可以找出其中很多异味。那么应该怎么样来规定依赖关系呢？

单一职责原则（The Single Responsibility Principle - SRP）
一个类只能因为一个原因而改变
在UML图中，找一找那些与多个主题域存在依赖关系的类。
开放-封闭原则（The Open-Close Principle - OCP）
软件实体（类、模块、方法等）应该允许扩展，不许修改
应该可在不改变模块本身的情况下改变模块周围的环境
里斯科夫替换原则（The Liskov Subsitution Principle - LSP）
子类型必须能够替代它们的基类型
LSP指出，基类用户不必为了使用派生类而做任何特殊的事情。确切的说，它们不应该需要使用instanceof，也不必向下转型。实际上，它们根本不需要了解派生类，甚至不必知道是否存在派生类。
依赖关系倒置原则（The Dependency Inversion Principle - DIP）
A.上层模块应该不依赖于下层模块。它们都依赖于抽象。
B.抽象应该不依赖于细节。细节应该依赖于抽象。
不要依赖易变的具体类。从UML的角度看，顺着UML图中的每个箭头，检查箭头的顶端指向的是否是一个接口或抽象类。如果不是，而且指向的具体类是会改变的，那么就违反了DIP。
接口隔离原则（The Interface Segregation Principle - ISP）
客户端不应该依赖于自己不用的方法。
遵循一个简单的规则——为使用者提供只包含了它们要用到的方法的接口——就可以保护使用者被不用的方法影响

运用这些原则的最好方式是有的放矢，而不是”主动出击“。

发表于 @ 2008年10月28日　14:18:00 | 评论( loading... ) | 编辑| 举报| 收藏

旧一篇:OOA/D学习笔记(1) | 新一篇:扩展Struts
查看最新精华文章 请访问博客首页相关文章
  • 发表评论
  • 评论内容：
  •  
Copyright © rgbwoo
Powered by CSDN Blog