一些设计上的基本常识

标签: 设计 常识 | 发表时间:2015-02-03 15:21 | 作者:cyc315
出处:http://www.iteye.com

转自阿里梁飞的BLOG:
http://javatar.iteye.com/blog/706098

最近给团队新人讲了一些设计上的常识,可能会对其它的新人也有些帮助,
把暂时想到的几条,先记在这里。

1. API与SPI分离

框架或组件通常有两类客户,一个是使用者,一个是扩展者,
API(Application Programming Interface)是给使用者用的,
而SPI(Service Provide Interface)是给扩展者用的,
在设计时,尽量把它们隔离开,而不要混在一起,
也就是说,使用者是看不到扩展者写的实现的,
比如:一个Web框架,它有一个API接口叫Action,
里面有个execute()方法,是给使用者用来写业务逻辑的,
然后,Web框架有一个SPI接口给扩展者控制输出方式,
比如用velocity模板输出还是用json输出等,
如果这个Web框架使用一个都继承Action的VelocityAction和一个JsonAction做为扩展方式,
要用velocity模板输出的就继承VelocityAction,要用json输出的就继承JsonAction,
这就是API和SPI没有分离的反面例子,SPI接口混在了API接口中,
合理的方式是,有一个单独的Renderer接口,有VelocityRenderer和JsonRenderer实现,
Web框架将Action的输出转交给Renderer接口做渲染输出。







2. 服务域/实体域/会话域分离

任何框架或组件,总会有核心领域模型,比如:
Spring的Bean,Struts的Action,Dubbo的Service,Napoli的Queue等等
这个核心领域模型及其组成部分称为实体域,它代表着我们要操作的目标本身,
实体域通常是线程安全的,不管是通过不变类,同步状态,或复制的方式,
服务域也就是行为域,它是组件的功能集,同时也负责实体域和会话域的生命周期管理,
比如Spring的ApplicationContext,Dubbo的ServiceManager等,
服务域的对象通常会比较重,而且是线程安全的,并以单一实例服务于所有调用,
什么是会话?就是一次交互过程,
会话中重要的概念是上下文,什么是上下文?
比如我们说:“老地方见”,这里的“老地方”就是上下文信息,
为什么说“老地方”对方会知道,因为我们前面定义了“老地方”的具体内容,
所以说,上下文通常持有交互过程中的状态变量等,
会话对象通常较轻,每次请求都重新创建实例,请求结束后销毁。
简而言之:
把元信息交由实体域持有,
把一次请求中的临时状态由会话域持有,
由服务域贯穿整个过程。





3. 在重要的过程上设置拦截接口

如果你要写个远程调用框架,那远程调用的过程应该有一个统一的拦截接口,
如果你要写一个ORM框架,那至少SQL的执行过程,Mapping过程要有拦截接口,
如果你要写一个Web框架,那请求的执行过程应该要有拦截接口,
等等,没有哪个公用的框架可以Cover住所有需求,允许外置行为,是框架的基本扩展方式,
这样,如果有人想在远程调用前,验证下令牌,验证下黑白名单,统计下日志,
如果有人想在SQL执行前加下分页包装,做下数据权限控制,统计下SQL执行时间,
如果有人想在请求执行前检查下角色,包装下输入输出流,统计下请求量,
等等,就可以自行完成,而不用侵入框架内部,
拦截接口,通常是把过程本身用一个对象封装起来,传给拦截器链,
比如:远程调用主过程为invoke(),那拦截器接口通常为invoke(Invocation),
Invocation对象封装了本来要执行过程的上下文,并且Invocation里有一个invoke()方法,
由拦截器决定什么时候执行,同时,Invocation也代表拦截器行为本身,
这样上一拦截器的Invocation其实是包装的下一拦截器的过程,
直到最后一个拦截器的Invocation是包装的最终的invoke()过程,
同理,SQL主过程为execute(),那拦截器接口通常为execute(Execution),原理一样,
当然,实现方式可以任意,上面只是举例。



4. 重要的状态的变更发送事件并留出监听接口

这里先要讲一个事件和上面拦截器的区别,拦截器是干预过程的,它是过程的一部分,是基于过程行为的,
而事件是基于状态数据的,任何行为改变的相同状态,对事件应该是一致的,
事件通常是事后通知,是一个Callback接口,方法名通常是过去式的,比如onChanged(),
比如远程调用框架,当网络断开或连上应该发出一个事件,当出现错误也可以考虑发出一个事件,
这样外围应用就有可能观察到框架内部的变化,做相应适应。



5. 扩展接口职责尽可能单一,具有可组合性

比如,远程调用框架它的协议是可以替换的,
如果只提供一个总的扩展接口,当然可以做到切换协议,
但协议支持是可以细分为底层通讯,序列化,动态代理方式等等,
如果将接口拆细,正交分解,会更便于扩展者复用已有逻辑,而只是替换某部分实现策略,
当然这个分解的粒度需要把握好。

6. 微核插件式,平等对待第三方

大凡发展的比较好的框架,都遵守微核的理念,
Eclipse的微核是OSGi, Spring的微核是BeanFactory,Maven的微核是Plexus,
通常核心是不应该带有功能性的,而是一个生命周期和集成容器,
这样各功能可以通过相同的方式交互及扩展,并且任何功能都可以被替换,
如果做不到微核,至少要平等对待第三方,
即原作者能实现的功能,扩展者应该可以通过扩展的方式全部做到,
原作者要把自己也当作扩展者,这样才能保证框架的可持续性及由内向外的稳定性。

7. 不要控制外部对象的生命周期

比如上面说的Action使用接口和Renderer扩展接口,
框架如果让使用者或扩展者把Action或Renderer实现类的类名或类元信息报上来,
然后在内部通过反射newInstance()创建一个实例,
这样框架就控制了Action或Renderer实现类的生命周期,
Action或Renderer的生老病死,框架都自己做了,外部扩展或集成都无能为力,
好的办法是让使用者或扩展者把Action或Renderer实现类的实例报上来,
框架只是使用这些实例,这些对象是怎么创建的,怎么销毁的,都和框架无关,
框架最多提供工具类辅助管理,而不是绝对控制。

8. 可配置一定可编程,并保持友好的CoC约定

因为使用环境的不确定因素很多,框架总会有一些配置,
一般都会到classpath直扫某个指定名称的配置,或者启动时允许指定配置路径,
做为一个通用框架,应该做到凡是能配置文件做的一定要能通过编程方式进行,
否则当使用者需要将你的框架与另一个框架集成时就会带来很多不必要的麻烦,
另外,尽可能做一个标准约定,如果用户按某种约定做事时,就不需要该配置项。
比如:配置模板位置,你可以约定,如果放在templates目录下就不用配了,
如果你想换个目录,就配置下。

9. 区分命令与查询,明确前置条件与后置条件

这个是契约式设计的一部分,尽量遵守有返回值的方法是查询方法,void返回的方法是命令,
查询方法通常是幂等性的,无副作用的,也就是不改变任何状态,调n次结果都是一样的,
比如get某个属性值,或查询一条数据库记录,
命令是指有副作用的,也就是会修改状态,比如set某个值,或update某条数据库记录,
如果你的方法即做了修改状态的操作,又做了查询返回,如果可能,将其拆成写读分离的两个方法,
比如:User deleteUser(id),删除用户并返回被删除的用户,考虑改为getUser()和void的deleteUser()。
另外,每个方法都尽量前置断言传入参数的合法性,后置断言返回结果的合法性,并文档化。

10. 增量式扩展,而不要扩充原始核心概念



已有 0 人发表留言,猛击->> 这里<<-参与讨论


ITeye推荐



相关 [设计 常识] 推荐:

一些设计上的基本常识

- - 研发管理 - ITeye博客
转自阿里梁飞的BLOG:. 最近给团队新人讲了一些设计上的常识,可能会对其它的新人也有些帮助,. 框架或组件通常有两类客户,一个是使用者,一个是扩展者,. API(Application Programming Interface)是给使用者用的,. 而SPI(Service Provide Interface)是给扩展者用的,.

android几个常识

- - shell's home
    首先,总内存量需要被各种CPU划出部分使用,剩余才是系统可用内存. 这个概念差不多相当于电脑上的共享显存,系统对划走的内存是没有管理能力的,因此在/proc/meminfo中找不到这部分内存. 这部分内存既不能优化也不能使用,因此其实是不可使用内存. 厂家出厂内存(标称内存)和可使用内存一定存在差,具体多少看各种机型.

把常识当成信仰

- ppip - Pure Pleasure - Reborn
在与学生及其家长沟通的时候,我常常遇到这样的疑惑:. 听写没什么用,还是练习跟读吧⋯⋯. 课外活动经历在申请中的作用没那么大,除非,你的经历格外惊人,就好像TOEFL118分一样百里挑一⋯⋯. 先看题目而后只看阅读考试文章中“该看的部分”,这种说法纯属胡说八道,SAT这种考试是逻辑考试,Official Guide里说的很清楚:Every word counts….

从社区常识说起

- ZoOL - 设计思想 - UCD大社区
这篇文章全无深刻,只讲社区培育的一些常识. 虽说是大路货,操作的时候也可能遗漏一些东西,我最近就在自检时发现了漏洞. 先说说什么是“社区”,互联网上尚无公认的定义. 按我的看法,凡重视人际关系的内容产品,同时域内用户对整个用户群有较强的认同感,这就是社区. 它有三个典型特征,第一是用户产出内容,第二是通过用户关系来加强内容的互动与产出,第三是有着约定俗成的社区文化.

五险一金常识

- - CSDN博客综合推荐文章
        转载请说明出处,本文来自Android菜鸟: http://blog.csdn.net/android_cai_niao/article/details/43941803  QQ:2717521606.         以前一直不怎么关注五险一金,找工作的时候也没在意这个,现在好像有点头绪了,整理如下:       .

为了设计而设计

- - 幻风阁|kent.zhu'sBlog
我有个习惯,每天晚上睡前会搜罗一遍最新的App用用. 最开始的时候ios的App还相对比较朴实,强调功能的实用性,后来不知何故吹起一阵ios的App必须足够精美的怪风. 于是乎,各类App纷纷上演换装游戏,一个比一个做的精美,即使是一个很工具性的应用也把自己浓妆艳抹的往坐台小姐的风格搞……. 上周末跟Tony和Angela在下厨房喝茶闲聊,我说目前的移动产品设计可以分为2类,一类是做给用户用的,一类是做给设计师们欣赏与收藏的.

「常识」厨房清洁小妙招

- Winterth - 下厨房
在中国的传统习俗里,过年前一定要有一次彻底的大扫除,意在“辞旧迎新”. M认为,彻底的大扫除不应该只在过年做,平时也要多做彻底的清洁,尤其是厨房,因为“病从口入”嘛. M特别整理了一些关于厨房清洁的小妙招,在这里和大家一起分享一下: 1、抽油烟机的清洁. 说到厨房的清理,最恐怖的一项就是抽油烟机了.

「常识」原奶标准那些事儿

- nfwater - 下厨房
“原奶标准全世界最低”是什么意思. 巴氏灭菌奶和超高温灭菌奶到底孰优孰劣. 下厨房特别分享《关于原奶标准——一个业内人士和家人的对话》这篇通俗易懂的科普文章给大家,关于食品的知识,多储备一点儿总不会有错. 周末见到婆婆,第一句话就是,“哎,听说现在中国的牛奶标准全世界最差啊,是不是不能喝了. ”由此引出了我和她的一大段关于牛奶的讨论,记录在此.

保护头发的十个常识

- han - 果壳网 guokr.com - 果壳网
秀发,你能再“丰满”些吗. 头发的多少由基因决定,一般来说红发都比较厚重,金发虽数量最多但发丝细软. 改变不了基因,就只能顶着一头稀疏的头发吗. 有一个好办法就是使用一些硅酮类洗护发产品,如二甲基硅酮、环二甲基硅酮(一般洗护发产品中都有加入这些成分). 它们能在发丝表面形成一层薄膜,让头发看上去丰满不油腻,既便清洗之后,仍然能保留在头发上,方便有效.