Design
文章平均质量分 67
RayChase
博客搬家了: https://www.raychase.net/
展开
-
使用Groovy的Adapter模式来处理遗留代码
使用Groovy的Adapter模式来处理遗留代码如果使用Java语言,针对一个遗留的类Circle,需要建立一个接口,再建立新类和遗留类的适配器实现该接口,再建立一个控制器:/**//* * Adapter模式经常用来处理遗留代码 */package com.XiongYi.designPatterns;//遗留代码 Circle类 方法drawCircle() 这个类不便做更改cl原创 2008-05-11 02:03:00 · 1084 阅读 · 0 评论 -
从错误页面的角度看用户体验
<br />阶段一:<br />系统错误信息乃至错误堆栈被抛到页面上。<br />这是最原始的容错界面,在现在的网站中依然偶尔出现,这是糟糕的和不安全的,相信现在没有一个负责任的UCD专家会容忍这种现象的发生。<br /> <br />阶段二:<br />引导到简单的错误提示页面,例如:“系统忙”、“页面不存在”和“出错了”,或者一个简单的弹出框提示用户。<br />无论界面是美观还是简陋,这种方式都是原始的,并且是易于实现的。这是网站UCD的底线,如果您希望您的网站简单和质朴,那么这样实现并没有什么不好。原创 2011-04-09 00:31:00 · 1024 阅读 · 0 评论 -
J2EE 核心模式(Core J2EE Patterns)学习随心理解、随手记录(汇总帖)
J2EE 核心模式(Core J2EE Patterns)学习随心理解、随手记录(一) J2EE 核心模式(Core J2EE Patterns)学习随心理解、随手记录(二) J2EE 核心模式(Core J2EE Patterns)学习随心理解、随手记录(三) J2EE 核心模式(Core J2EE Patterns)学习随心理解、随手记录(四) J2EE 核心模式(Core J2EE Patterns)学习随心理解、随手记录(五) J2EE 核心模式(Core J2EE Patterns)学习原创 2011-05-15 21:33:00 · 1603 阅读 · 1 评论 -
代码的变和不变
哲学上说变与不变,讲的是绝对运动与相对静止的道理,在代码设计中,也有许多变和不变之间的辩证故事。 有一些类在创建以后,整个生命周期内都不会发生变化,这种模式被称为Immutable Pattern。 较弱的不变模式:指的是一个类的实例状态是不可变化的,但是这个类的引用的实例却可以变化。 比如说:Visitor模式常常是这样的,整个流程是不可变的,但是我为我的整个流程提供灵活的切入点,提供出来访问接口,供变化的部分完成。 较强的不变模式:一个类实例状态不可变,其内部引用的所有实例也不可变。 这原创 2011-03-14 23:51:00 · 990 阅读 · 0 评论 -
功能、模块质量和非功能性测试
<br />但凡面向终端用户的产品,产品做大了以后,几乎都要涉及到基线能力和定制能力的划分。任何一个优秀的产品,都要经历从相对无序到有序的逐步成熟的过程。产品的发展总是要经历不断的阵痛,可是时间长了,我还是总免不了思考:好吧,就算产品最初匆忙和艰辛的时期已经过去,就算现在基线能力的建设已经迈入正轨,可是为什么我们的直接客户,定制团队还是那么辛苦?<br /> <br />有多少功能是真正值得去完成、真正被用户所需要的?<br />据一位定制的兄弟说,其实这个比例只有8%,我相信数据也许是不准确的,但不管数据原创 2011-03-09 23:48:00 · 2054 阅读 · 0 评论 -
J2EE 核心模式(Core J2EE Patterns)学习随心理解、随手记录(七)
Web Service中转:暴露可通过XML和web协议访问的服务,并将对服务的请求转发给真实的服务组件。通常有许多Web Service是不希望暴露出来的,有时有一些服务又需要聚合起来使用,这时候就需要Web Service中转。在使用中转前的Web Service需要被改造,以支持中转的接口(例如一个本地接口)。这个模式和Facade很类似,只不过它的定位放在了远程接口上。 微架构:一组被同时使用的模式,用于实现系统中的一个特定部分(子系统)。每一个微架构是独立和内聚的积木块,由它们构成整个系统原创 2011-02-20 12:50:00 · 1051 阅读 · 0 评论 -
J2EE 核心模式(Core J2EE Patterns)学习随心理解、随手记录(六)
集成层模式: 数据访问对象:Data Access Object。提炼和封装对持久化存储介质的访问。DAO封装了数据源的实现细节,总是面向API调用者提供统一的接口。DAO应当被实现为无状态的对象,这样就可以成为轻量的对象,不需要考虑线程、同步、缓存等问题,而把这些问题下沉到数据层去完成。 以我参与的项目的缓存的使用举例,模型DAO并不做任何的缓存行为,数据库使用自身的缓存能力,并且在必要时冗余字段,这是基于数据粒度的基础缓存;到了调用DAO的业务层面,比如Service层,才进行业务模型粒度的缓原创 2011-02-18 00:35:00 · 1119 阅读 · 0 评论 -
J2EE 核心模式(Core J2EE Patterns)学习随心理解、随手记录(五)
业务对象:利用对象模型把业务数据和业务逻辑分离开来。业务对象在最前端(客户端)和最后端(数据资源)都会进行业务数据形式的转化。业务对象的实现通常有两种方式:POJO + JDO 或者 Entity Bean + BMP/CMP。业务对象包含业务逻辑和业务状态。 J2EE系统中面向过程向面向对象转变有时甚至仅仅区别于最初的一念之差。没有什么是绝对的事情,如果业务非常简单,客户端通过浅浅的显示层,直接访问持久层、甚至数据资源存储中业务数据,整个过程中,其结构都是依据客户端所需数据的获取过程来完成的,是典型的面原创 2011-02-15 00:08:00 · 1232 阅读 · 0 评论 -
J2EE 核心模式(Core J2EE Patterns)学习随心理解、随手记录(一)
第1章:导论。 模式能够: 利用一个经过验证可行的解决方案; 提供一套通用词汇; 约束解决方案的空间。 第2章:表现层设计考虑和不佳实践。 客户端验证:基于表单的验证、基于抽象类型的验证。 曾经在JSP中滥用过的助手类,通过助手类在页面和业务逻辑之间传递数据,有点类似于如今Struts中的Action作为传值模型时的情况。 表现层不佳实践: 多个视图中都包含控制代码; 表现层数据结构暴露给业务层或者业务领域对象,比如:暴露HTTPServletRequest; 重复提交表单;原创 2011-02-08 23:47:00 · 3569 阅读 · 0 评论 -
J2EE 核心模式(Core J2EE Patterns)学习随心理解、随手记录(四)
业务层模式: 业务代表:Business Delegate。封装对业务服务的访问,隐藏服务层具体实现细节,主要为降低客户端和服务层之间的耦合。除了隐藏服务细节、处理服务异常等基础功能以外,还可以做服务的缓存。业务代表是客户端的直接客户,起到客户端业务抽象层的作用,而业务代表的另一头,常常连接着会话门面。 比较常用的情况就是在某种远程连接和业务处理的基础上,使用业务代表把这些细节统统包装起来,给内部提供的模型也好API也好,都是和外部接口相异的。比如一个系统中对于展现的内容数据的同步,以及订购、使用原创 2011-02-11 22:47:00 · 1264 阅读 · 0 评论 -
J2EE 核心模式(Core J2EE Patterns)学习随心理解、随手记录(三)
复合视图:Composite View。使用由多个原子化的子视图构成的复合视图。特点是组合是可以动态的,而页面布局又可以整体控制,和页面内容互相独立。 有这么几个常见的例子:Portlet就是一个复合视图结合的最好例子,主题可以影响到所有视图的呈现,又是和展示的具体内容没有关系的,Portlet可以在服务端做到视图的聚合,而不把事情遗留到客户端完成,不涉及浏览器跨域的安全性问题;SiteMesh是一个很适合对页眉、页脚等页面通用元素拼装的框架,比jsp:include标签优雅;更小维度上,标签的引用也可以原创 2011-02-10 23:30:00 · 1549 阅读 · 0 评论 -
J2EE 核心模式(Core J2EE Patterns)学习随心理解、随手记录(二)
我看的资料和这幅图有一些出入。 资料要去这里找:http://java.sun.com/blueprints/corej2eepatterns/Patterns/index.html 表现层模式: 拦截过滤器:Intercepting Filter。正如图中的“Apply zero or more”和Servlet规范所述一样,应当具备一个链式结构。这个链式结构中的每个filter,互相之间应当是一个互不依赖的松耦合关系,以便于容易地组合。 前端控制器:Front Contro原创 2011-02-09 23:27:00 · 1873 阅读 · 0 评论 -
API风云录
好吧,我承认我是标题党,还是让我们从一个故事开始吧。 项目的业务逻辑层需要被设计成一个具备易扩展的模式,对外提供了大小相异的API。项目组人人头脑风暴,最后在各位的努力下,克服苦难,业务逻辑层被封装起来,一组最初的API被提供出来: 1、现有Service逻辑已经疏于管理,欠缺重构,变成了不易控制的逻辑层,接口众多,鱼龙混杂,难以规整出清晰、可用的接口给第三方(例如下游定制团队),怎么办? Web应用有个特点,当你对代码的管理缺乏控制而搞不定时,可以在其上封装一层,这是一个通用的解决办法,也是一柄原创 2011-02-27 18:29:00 · 1044 阅读 · 0 评论 -
Flash Scope
项目中遇到了一个潜在的问题,大致就是说,在一个流程的两个或某几个环节中,需要短暂地存储一部分对象(如果不存储,就需要在这几个环节中多次调用同一个外部接口,这被认为是不够合理的实现)。 而这部分对象的存储: (1)如果用request,太小,毕竟一次提交以后就丢失了,如果需要往后传递,可能需要借助一些页面参数传值等丑陋或是不易控制的方法; (2)如果用session,太大,我不需要在整个用户会话生命周期内使用,而且如果同个用户并行地操作两个流程,期间会互相影响到。 其实在Rails/Grails里面就原创 2011-01-26 23:12:00 · 2342 阅读 · 0 评论 -
过度工程
最初我知道这个词是在Rod Johnson的《J2EE Development without EJB》,随着阅历地增长,渐渐发现书中熟悉的场景也在身边再现了。 敏捷、还有设计模式,给一个团队带来了什么? 我之所以把这两个词放在一起讲,是因为我要说一件显而易见的事情,可是这样一件事情很多人又不愿承认。 团队,是有风格个性的;团队,也是有能力强弱的。不管你承认不承认,整体来说,我们都还不是精英团队,因此相对于某些公司成功的案例来说,我们有很多事是不适合做的。 敏捷强调了主动性,强调了沟通,事实上原创 2011-04-30 22:25:00 · 1624 阅读 · 0 评论