一个简单的 POJO factory 实现

很简单,看看代码就明白了,不比 “hello,world” 复杂 。 主入口类 ServiceFactory 类似于 spring 的 BeanFactory: /** * * @author javafuns */ public class ServiceFactory { private static Map beansMap = Configuration.getInstance().getAllServices(); private ServiceFactory() { } public static T getService(Class superClaz) throws XxxException { String serviceClazShortName = BeanUtil.getClassShortName(superClaz); String impl = beansMap.get(serviceClazShortName); if (isBlank(impl)) { throw new XxxException(); } try { [...]

By javafuns on September 25, 2009 at 14:07 · Views: 326 · Permalink · RSS · Leave a comment
Categorized in: Design Patterns, Java · Tagged with: , ,

软件及服务的松耦合

软件的模块性: 模块可分解性(Modular Decomposability)——如果一种软件构造方法能有助于把一个软件问题分解为若干较简单的子问题、并用一个简单的结构将这些子问题连接起来、而且能够独立地对各个子问题作进一步分解,那么该方法就满足模块可分解性。 模块可组合性(Modular Composability)——如果一种方法,由它生产出的软件元素,未来可在不同于最初被开发的环境中通过彼此自由组合的方式来产生新的系统,那么该方法就满足模块可组合性。 模块可理解性(Modular Understandability)——如果一种方法,由它生产出的软件,人类读者无需了解其他模块(或最多只需研究少许其他模块)便可理解每一个模块,那么该方法就有利于模块可理解性。 模块连续性(Modular Continuity)——如果一种方法,在由它得到的软件架构中,功能规格上的微小改动只会引起一个(或少量)模块的变化,那么该方法就满足模块连续性。 模块保护性(Modular Protection)——如果一种方法,在由它得到的架构中,一个模块在运行时出现异常条件不会影响到该模块之外(或最多只蔓延到少数周边模块),那么该方法就满足模块保护性。 服务的模块性: 可分解性(Decomposability)——如果一种方法能有助于把一个软件问题分解为若干较简单的子问题、并用一个简单的结构将这些子问题连接起来、而且能够独立地对各个子问题作进一步分解,那么该方法就满足可分解性。 可组合性(Composability)——如果一种方法,由它生产出的软件元素,未来可在不同于最初被开发的环境中通过彼此自由组合的方式来产生新的系统,那么该方法就满足可组合性。 可理解性(Understandability)——如果一种方法,由它生产出的软件,人类读者无需了解其他模块(或最多只需研究少许其他模块)便可理解每一个模块,那么该方法就有利于可理解性。 连续性(Continuity)——如果一种方法,在由它得到的软件架构中,功能规格上的微小改动只会引起一个(或少量)模块的变化,那么该方法就满足连续性。 保护性(Protection)——如果一种方法,在由它得到的架构中,一个模块在运行时出现异常条件不会影响到该模块之外(或最多只蔓延到少数周边模块),那么该方法就满足保护性。 自查性(Introspection)——如果一个方法,由它得到的架构提供了“允许在运行时查询并检查模块结构及模块间通信结构”的机制,那么该方法就满足自查性。 远程性(Remoteability)——如果一个方法,由它得到的架构提供了“允许托管于不同物理环境下的不同模块与之进行模块通信”的机制,那么该方法就满足远程性。 异步性(Asynchronicity)——如果一个方法,由它得到的架构不假定模块调用将被立即响应,那么该方法就满足异步性。换言之,它假定网络或被调用模块有延迟。 面向文档(Document Orientedness)——如果一个方法,在由它得到的架构中,内部模块间的通信消息均是明确定义且互相知道的、而且各次调用之间不存在隐式的状态共享,那么该方法就是面向文档的。 标准化的协议信封(Standardized Protocol Envelope)——如果一个方法,由它得到的架构要求所有模块通信都共用一种通用信封消息格式,那么该方法就满足标准协议信封。 分散式管理(Decentralized Administration)——如果一个方法,由它得到的架构不需要对所有模块进行集中管理,那么该方法就符合分散式管理。 原文: SOA定义的松耦合 Loose Coupling in SOA Defined

By javafuns on April 20, 2009 at 15:50 · Views: 345 · Permalink · RSS · Leave a comment
Categorized in: Design Patterns, SOA · Tagged with: , ,

实现一个排斥性(exclude)过滤器

说到排斥性过滤器,大家会一头雾水,搞不明白这其中含义。何为排斥性(exclude)过滤器呢,其实是本人自己定义出来的,呵呵。 排斥性过滤器是相对于规范所定义的Filter而言的,Java EE 规范中的过滤器是对web.xml中所列出的url进行过滤,而排斥性过滤器则恰恰相反,不对这些web.xml中列出的url执行过滤,而是对除这些url外的url进行过滤逻辑操作。 作为一个多年的Java开发人员,在实际开发中遇到这种情况,这便是有此动机的原因。 下面就讲讲这个exclude filter的原理,其实很简单。在拦截所有请求时,我们检查这些请求的url是否在url列表之内,如果在,那么就不进行过滤逻辑,直接调用chain.doFilter(xxx);否则的话,我们就执行一些过滤逻辑操作,然后再chain.doFilter(xxx)。 其中,检查url分2种方式:精确匹配(equals)和模糊匹配(contains),精确匹配优先于模糊匹配 对于代码中的URI获取,可能要根据实际情况作些更改,代码中URI只是使用request.getRequestURI(),得到的不是完整的URL,可视实际情况做出调整。 AbstractExcludeFilter 类将不该被override的方法都设置为了final,developer应该实现唯一的一个abstract method filter(),并且需要在该方法内部适当位置调用 chain.doFilter(xx)。 请看实现代码:

By javafuns on May 1, 2008 at 19:19 · Views: 552 · Permalink · RSS · Leave a comment
Categorized in: Design Patterns, Java · Tagged with: ,

Encapsulate What Varies Principle — 读《Head first Design Patterns》

Design Principle Identify the aspects of your application that vary and separate them from what stays the same 意思是,要尽可能把变化的部分与不变的部分分离开.

By javafuns on April 27, 2008 at 21:15 · Views: 699 · Permalink · RSS · Leave a comment
Categorized in: Design Patterns · Tagged with: ,

Singleton Pattern 的几种方式

public class Singleton { private final static Singleton instance = new Singleton(); // Private constructor suppresses generation of a (public) default constructor private Singleton() {} public static Singleton getInstance() { return instance; } } public class Singleton { private static Singleton instance; // Private constructor suppresses generation of a (public) default constructor private Singleton() {} [...]

By javafuns on May 17, 2007 at 23:54 · Views: 629 · Permalink · RSS · Leave a comment
Categorized in: Design Patterns, Java · Tagged with: ,

Dependency Inversion Principle — 读《Head first Design Patterns》

Design Principle Depend upon abstractions. Do not depend upon concrete classes.

By javafuns on May 16, 2007 at 00:13 · Views: 658 · Permalink · RSS · Leave a comment
Categorized in: Design Patterns, Java · Tagged with: ,

The Open-Closed Principle — 读《Head first Design Patterns》

Another new OO design principle: Design Principle Classes should be open for extension, but closed for modification e.g. Decorator Pattern

By javafuns on May 15, 2007 at 00:14 · Views: 814 · Permalink · RSS · Leave a comment
Categorized in: Design Patterns, Java · Tagged with: ,

Loose Coupling — 读《Head first Design Patterns》

The next principle i got is : Design Principle: Strive for loosely coupled designs between objects that interact

By javafuns on May 11, 2007 at 00:22 · Views: 569 · Permalink · RSS · Leave a comment
Categorized in: Design Patterns, Java · Tagged with: ,
  • Highest Rated

  • My PicasaPhotos

    4b8ffd7a3a6deafe2f73b3e2.jpg

    IMG_0547.JPG

    IMG_0545.JPG

  • RSS My del.icio.us

  • My RSS