随笔档案

SRP的理念最早由Tom DeMarco提出,并作为内聚性的一个重要组成部分

  *此处的Object不同于OO中类的实例,按照面向过程编程,一个function也可以称为一个Object

Bob大叔在面向对象领域重新诠释了该原则(下载Bob大叔的诠释).并归于他的面向对象设计的原则之一.

Bob大叔指出:

 Bob大叔的观点和Tom的观点有相当大的差异,Tom强调一个Object只能有一个职责,而Bob强调一个类只能有一个产生变化的原因。那Bob到底要表达什么呢，一个类是只能有一个功能(职责)?如果一个类真的只能有一个方法,那我们程序中的类不多了去了.带着疑问, 我们看一下Bob书《Agile Software Development: Principles, Patterns, and Practices.》中的原文

 原来Bob大叔说的是单一职责是要高内聚，这就对了。那我们的类究竟该如何设计呢？综合起来,SRP原则包括两个方面

 1.高内聚:在某种意义上高内聚意味者好的抽象,既尽可能多的忽略无关的细节.其目标是降低复杂度.具体说来就是:

如果我们在BOM系统中需要一个Materil类,初始化后能获取名称,主要供应商,查找所有供应商等外部接口

   Materiel类的接口

Materiel类的对外接口都为一个为物料的抽象性服务,虽然Material内部实现有其它服务该类的其它属性,比如说BasicInfoDAL.Material,BasicInfoDAL.Vendor两个类.但对于Material类的客户(调用者)并不知道,也不需知道其内部实现.

2.隔离易变化点: 此处为Bob大叔的核心观点,也是大多数书上,网上关于SRP的观点.目标是便于重用和减少修改成本,常见做法就是将类拆分.
  

违反SRR意味着把本不相关的的职责耦合在一起.从而导致易碎的"瓷器设计",让后来者甚至原作者在一段时间之后也

不敢轻易动该类,最后常见的情况就是为每个调用者拷贝一份代码,另外起一个名字。使设计腐化；

   违反该类的常见情景有：

1. 过大的类；
2. 万能类/大杂烩类；
3. 业务逻辑与持久化处理不分
4. 业务逻辑与GUI处理部分
5. 特别要提一下的是新手程序员常犯的错误，万能超级页面

过大的类：常见代码臭味之一,产生原因是加给类做的事情太多.一搬情况下,按我个人平时的做法要是一个类公开的方法超过7个/或代码超过300行就可以检查是否可以改进了.

万能类/大杂烩类:什么都能干,什么都知道的类.大杂烩类在一些企业很常见,甚至有一个标准的名称 Common.cs,任何想的到的想不到的东东都往里面加.处理方法,建议大家在有建Common的时侯稍微动一下艺术细胞,想一个好类名.杜绝Common.cs

业务逻辑与持久化处理不分:常见情况是没有独立的DAL层,逻辑与SQL写在一个方法里.走一步代码,拼成一个SQL语句,查出数据核对下结果.不停的重复.程序慢了之外,维护还是个大问题

业务逻辑与GUI处理部分:常见情况是往类里面传控件,甚至类里面本身就有frm**的引用.非form类的方法里有*.Text="***";或int xxx=Convert.ToInt32(**.Text.Trim())类似代码;*.Enable=true类似代码.

万能超级页面: 这个名字享受加红的特殊待遇有两个;一是因为这个东东很常见,带过新人的兄弟肯定有过忘界面兴叹的郁闷.没带过的估计前不久自己还这么干.咱以前也干过,

   此种问题一旦出现,整个项目不带aspx的cs文件不会3个,除此之外全部是界面,所有的操作都在页面,甚至全部在***_Click(object sender,**EventArg e)中完成.此种超级页面称为万能页面. 碰到业务逻辑复杂一点的,代码行数会不断刷新记录.按照微软一份统计,大型团队人均年代码率3K行的标准,你会发现,一个万能超级页面就能轻松胜出一个工程师一年的产出,还能留个零数来年备用.

---------------------------------------------------------------------------------------------------

难得周末这么清闲,聊下最基本最简单的OO原则,文章构思,生成时间较短,必定很多不足与错误,欢迎指出, 另外做个小统计

你见过的最长代码文档有多长?

我自己见过最长的代码文档(*.aspx+*.aspx.cs) 有4k行,约等16人月产出