----------Arthur J.Riel

(1)所有数据都应该隐藏在所在的类的内部。

(2)类的使用者必须依赖类的共有接口，但类不能依赖它的使用者。

(3)尽量减少类的协议中的消息。

(4)实现所有类都理解的最基本公有接口[例如，拷贝操作(深拷贝和浅拷贝)、相等性判断、正确输出内容、从ASCII描述解析等等]。

(5)不要把实现细节(例如放置共用代码的私有函数)放到类的公有接口中。
如果类的两个方法有一段公共代码，那么就可以创建一个防止这些公共代码的私有函数。

(6)不要以用户无法使用或不感兴趣的东西扰乱类的公有接口。

(7)类之间应该零耦合，或者只有导出耦合关系。也即，一个类要么同另一个类毫无关系，要么只使用另一个类的公有接口中的操作。

(8)类应该只表示一个关键抽象。
包中的所有类对于同一类性质的变化应该是共同封闭的。一个变化若对一个包影响，则将对包中的所有类产生影响，而对其他的包不造成任何影响 .

(9)把相关的数据和行为集中放置。
设计者应当留意那些通过get之类操作从别的对象中获取数据的对象。这种类型的行为暗示着这条经验原则被违反了。

(10)把不相关的信息放在另一个类中(也即：互不沟通的行为)。
朝着稳定的方向进行依赖.

(11)确保你为之建模的抽象概念是类，而不只是对象扮演的角色。

(12)在水平方向上尽可能统一地分布系统功能，也即：按照设计，顶层类应当统一地共享工作。

(13)在你的系统中不要创建全能类/对象。对名字包含Driver、Manager、System、Susystem的类要特别多加小心。
规划一个接口而不是实现一个接口。

(14)对公共接口中定义了大量访问方法的类多加小心。大量访问方法意味着相关数据和行为没有集中存放。

(15)对包含太多互不沟通的行为的类多加小心。
这个问题的另一表现是在你的应用程序中的类的公有接口中创建了很多的get和set函数。

(16)在由同用户界面交互的面向对象模型构成的应用程序中，模型不应该依赖于界面，界面则应当依赖于模型。

(17)尽可能地按照现实世界建模(我们常常为了遵守系统功能分布原则、避免全能类原则以及集中放置相关数据和行为的原则而违背这条原则) 。

(18)从你的设计中去除不需要的类。
一般来说，我们会把这个类降级成一个属性。

(19)去除系统外的类。
系统外的类的特点是，抽象地看它们只往系统领域发送消息但并不接受系统领域内其他类发出的消息。

(20)不要把操作变成类。质疑任何名字是动词或者派生自动词的类，特别是只有一个有意义行为的类。考虑一下那个有意义的行为是否应当迁移到已经存在或者尚未发现的某个类中。

(21)我们在创建应用程序的分析模型时常常引入代理类。在设计阶段，我们常会发现很多代理没有用的，应当去除。

(22)尽量减少类的协作者的数量。
一个类用到的其他类的数目应当尽量少。

(23)尽量减少类和协作者之间传递的消息的数量。

(24)尽量减少类和协作者之间的协作量，也即：减少类和协作者之间传递的不同消息的数量。

(25)尽量减少类的扇出，也即：减少类定义的消息数和发送的消息数的乘积。

(26)如果类包含另一个类的对象，那么包含类应当给被包含的对象发送消息。也即：包含关系总是意味着使用关系。

(27)类中定义的大多数方法都应当在大多数时间里使用大多数数据成员。

(28)类包含的对象数目不应当超过开发者短期记忆的容量。这个数目常常是6。
当类包含多于6个数据成员时，可以把逻辑相关的数据成员划分为一组，然后用一个新的包含类去包含这一组成员。

(29)让系统功能在窄而深的继承体系中垂直分布。

(30)在实现语义约束时，最好根据类定义来实现。这常常会导致类泛滥成灾，在这种情况下，约束应当在类的行为中实现，通常是在构造函数中实现，但不是必须如此。

(31)在类的构造函数中实现语义约束时，把约束测试放在构造函数领域所允许的尽量深的包含层次中。

(32)约束所依赖的语义信息如果经常改变，那么最好放在一个集中式的第3方对象中。

(33)约束所依赖的语义信息如果很少改变，那么最好分布在约束所涉及的各个类中。

(34)类必须知道它包含什么，但是不能知道谁包含它。

(35)共享字面范围(也就是被同一个类所包含)的对象相互之间不应当有使用关系。

(36)继承只应被用来为特化层次结构建模。

(37)派生类必须知道基类，基类不应该知道关于它们的派生类的任何信息。

(38)基类中的所有数据都应当是私有的，不要使用保护数据。
类的设计者永远都不应该把类的使用者不需要的东西放在公有接口中。

(39)在理论上，继承层次体系应当深一点，越深越好。

(40)在实践中，继承层次体系的深度不应当超出一个普通人的短期记忆能力。一个广为接受的深度值是6。

(41)所有的抽象类都应当是基类。

(42)所有的基类都应当是抽象类。

(43)把数据、行为和/或接口的共性尽可能地放到继承层次体系的高端。

(44)如果两个或更多个类共享公共数据(但没有公共行为)，那么应当把公共数据放在一个类中，每个共享这个数据的类都包含这个类。

(45)如果两个或更多个类有共同的数据和行为(就是方法)，那么这些类的每一个都应当从一个表示了这些数据和方法的公共基类继承。

(46)如果两个或更多个类共享公共接口(指的是消息，而不是方法)，那么只有他们需要被多态地使用时，他们才应当从一个公共基类继承。

(47)对对象类型的显示的分情况分析一般是错误的。在大多数这样的情况下，设计者应当使用多态。

(48)对属性值的显示的分情况分析常常是错误的。类应当解耦合成一个继承层次结构，每个属性值都被变换成一个派生类。

(49)不要通过继承关系来为类的动态语义建模。试图用静态语义关系来为动态语义建模会导致在运行时切换类型。

(50)不要把类的对象变成派生类。对任何只有一个实例的派生类都要多加小心。

(51)如果你觉得需要在运行时刻创建新的类，那么退后一步以认清你要创建的是对象。现在，把这些对象概括成一个类。

(52)在派生类中用空方法(也就是什么也不做的方法)来覆写基类中的方法应当是非法的。

(53)不要把可选包含同对继承的需要相混淆。把可选包含建模成继承会带来泛滥成灾的类。

(54)在创建继承层次时，试着创建可复用的框架，而不是可复用的组件。

(55)如果你在设计中使用了多重继承，先假设你犯了错误。如果没犯错误，你需要设法证明。

(56)只要在面向对象设计中用到了继承，问自己两个问题：(1)派生类是否是它继承的那个东西的一个特殊类型？(2)基类是不是派生类的一部分？

(57)如果你在一个面向对象设计中发现多重继承关系，确保没有哪个基类实际上是另一个基类的派生类。

(58)在面向对象设计中如果你需要在包含关系和关联关系间作出选择，请选择包含关系。

(59)不要把全局数据或全局函数用于类的对象的薄记工作。应当使用类变量或类方法。

(60)面向对象设计者不应当让物理设计准则来破坏他们的逻辑设计。但是，在对逻辑设计作出决策的过程中我们经常用到物理设计准则。

(61)不要绕开公共接口去修改对象的状态。

    简单来说，Design Patten 就是一个常用的方案。 在我们的开发过程中，经常会遇到一些相同或者相近的问题，每次我们都会去寻找一个新的解决方法，为了节省时间提高效率，我们提供一些能够解决这些常见问题的，被证实可行的方案，构成一个统一的资源库。
    一个Design Patten描述了一个被证实可行的方案。这些方案非常普通，是有完整定义的最常用的模式。 这些模式可以被重用，有良好的伸缩性，而这些Design Patten的优势将在设计J2EE应用时得到体现。

1. Model-View-Controller

a. 问题
    如果开发一个企业级应用，只需要一种客户端的话，那么一切都非常容易解决。但真实情况是，我们必须面对运行在各种设备上客户端，象PDA，WAP浏览器以及运行在桌面上的浏览器，我们不得不开发不同的应用程序来处理来自不同客户端的请求。数据访问与现实将混淆在一起，可能会出现重复的数据访问，导致整个开发周期没有必要的延长。

b. 建议的解决方法
    Model-View-Controller (MVC) 开发模式被证明是有效的处理方法之一。它可以分离数据访问和数据表现。你可以开发一个有伸缩性的，便于扩展的控制器，来维护整个流程。如图1所示为整个模式的结构。MVC模式可以被映射到多层企业级的J2EE应用上。
§ 所有的企业数据以及商业逻辑可以作为模式。
§ 视图可以通过模式访问数据，并根据客户端的要求来显示数据。视图必须保证当模式改变的时候，数据显示也必须同时改变。
§ 控制器用来结合模式和视图，把客户端来的请求转换成模式能够理解并执行的请求，并且根据请求以及执行结果来决定下一次显示那一个视图。
根据以上的逻辑，你可以象这样建立一个应用：
§ 应用的商业逻辑由MVC中的模式也就是EJB来表现。模式必须处理由控制器传递过来的对数据的访问请求。
§ 多个页面组成了MVC中的视图，这些视图必须随模式一起更新。
§ 控制器是一系列接收用户动作的对象，他们把用户的请求转换成模式可理解的请求，并决定显示那一个页面当模式处理完请求后。

c. 要点
§ MVC结构适用于那些多用户的，可扩展的，可维护的，具有很高交互性的系统。
§ MVC可以很好的表达用户的交互和系统模式。
§ 很方便的用多个视图来显示多套数据，是系统很方便的支持其他新的客户端类型。
§ 代码重复达到最低。
§ 由于分离了模式中的流控制和数据表现，可以分清开发者的责任，另外，也可以加快产品推向市场的时间。

2. Front Controller

a. 问题
    MVC给出了一个整个应用的松散的耦合架构。现在来看一下这样一个经常发生的情况。在某一个应用中，用户看到的视图和他所做的操作密切相关。这是一些具有高度交互性的页面，而这些页面之间含有高度的依赖性。在没有任何模式的时候，这个应用只是一个许多独立的页面的集合，维护和扩展变得异常困难。
§ 当一个页面移动后，其他含有这个页面链接的文件，都必须修改。
§ 当有一系列页面需要口令保护时，许多配置文件需要修改，或者页面需要包含新的标记。
§ 当一个页面需要一个新的表示层时，页面中的标记要被重新安排。
    当这个系统变得复杂时，这些问题将变得更糟。如果用MVC来解决的话，就变成一个如何管理控制器和视图之间交互的问题。

b. 建议的解决方法
    前台控制模式可以解决这个问题。这个模式中，所有的请求都被传送到一个对象中。这个主要的对象将处理所有的请求，决定以后显示那一个视图，以及实现必要的安全需求。对于把视图显示以及其他功能实现集中到一个主要的对象中，将使修改变得很容易，对应用的修改，可以在所有视图中反映出来。

c. 要点
§ 这个模式对于需要在多个含有动态数据的页面之间进行复杂导航的系统来说，是很有效的。
§ 这个模式对于要在所有页面中都包含模板，转换等的应用来说，也是很有效的。
§ 由于视图的选择集中在前端控制器上，因此，视图的导航变得更加容易理解和便于配置。
§ 视图重用和变更会更加容易。
§ 视图之间的复杂交互，使得控制器变得复杂。从而，当应用发展的时候，控制器将变得难以维护。不过，大部分情况下可以用XML映射来解决。
§ 实现应用要求的安全性检验变得很简单。
§ 这个模式不适合小型的，只显示静态内容的应用。

d. 样例
§ RequestMappings.xml 文件映射了传入的请求，处理器以及下一个页面

useRequestHandler="true"
requiresSecurityCheck="true"
nextScreen="screen2.jsp">
com.blah1.blah2.blah3.request1Handler

    以上这个文件是控制器的指定配置，控制器的代码如下：
§ FrontControllerImpl.java 利用上面的XML实现了控制器
// all required imports
// exceptions to be caught appropriately wherever applicable

public class FrontControllerImpl extends HttpServlet {

// all required declarations, definitions
private HashMap requestMappings;

public void init() {
// load the mappings from XML file into the hashmap
}

public void doPost(HttpServletRequest request,
HttpServletResponse response)
throws IOException, ServletException
{
doGet(request, response);
}

public void doGet(HttpServletRequest request, HttpServletResponse response)
throws IOException, ServletException {
String currentPage= request.getPathInfo();
// get all mapping info for "currentPage" from the hashmap
// if "securityCheckRequired = true", do the security check
// if "useRequestHandler = true", pass on the incoming request to the specified handler
// forward the results to the given "nextScreen"
}
}
    用这种方法实现的控制器将很容易维护，当应用有新的变动的时候，只要修改XML文件就能解决了。前台控制模式将使在视图和控制器之前有复杂交互的J2EE应用变得简单。

3. Session Facade

a. 问题
    前台控制给出了一个基于MVC的，能有效管理用户与J2EE应用之间进行的复杂交互。这个模式可以使处理页面的现实顺序和用户的并发请求变得简单。并且使增加和改变页面现实变得更加容易。
另外一个常见的问题是，当EJB或者业务逻辑发生变化的时候，应用的客户端也必须随之改变。我们来看一下这个问题。
    一般来说，为了表现一个账户中的用户，我们使用一个业务逻辑来表示账户中的信息，象用户名和口令，再用一个EJB来管理用户的个人信息，象爱好，语言等。当要创建一个新的账号或者修改一个已经存在的账号时，必须访问包含账号信息的EJB，读取个人信息，修改并且保存，这样的一个流程。
    当然，这只是一个非常简单的例子，实际情况可能比这个复杂的多，象查看用户定制了哪些服务，检验客户信用卡的有效性，存放订单等。在这个案例中，为了实现一个完整的流程，客户端必须访问账户EJB来完成一系列适当的工作。下面的例子显示了一个Servlet客户端如何来控制一个用户订单。
A servlet that does the workflow required for placing an order
// all required imports;
// exceptions to be caught appropriately wherever applicable;
// This servlet assumes that for placing an order the account and
// credit status of the customer has to be checked before getting the
// approval and committing the order. For simplicity, the EJBs that
// represent the business logic of account, credit status etc are
// not listed

public class OrderHandlingServlet extends HttpServlet {

// all required declarations, definitions

public void init() {
// all inits required done here
}

public void doPost(HttpServletRequest request, HttpServletResponse response)
throws IOException, ServletException {
// other logic as required
// Get reference to the required EJBs
InitialContext ctxt = new InitialContext();
Object obj = ctxt.lookup("java:comp/env/ejb/UserAccount");
UserAccountHome acctHome = (UserAccountHome)
PortableRemoteObject.narrow(obj, UserAccountHome.class);
UserAccount acct = acctHome.create();
obj = ctxt.lookup("java:comp/env/ejb/CreditCheck");
CreditCheckHome creditCheckHome = (CreditCheckHome)
PortableRemoteObject.narrow(obj, CreditCheckHome.class);
CreditCheck credit = creditCheckHome.create();
obj = ctxt.lookup("java:comp/env/ejb/Approvals");
ApprovalsHome apprHome = (ApprovalsHome)
PortableRemoteObject.narrow(obj, ApprovalsHome.class);
Approvals appr = apprHome.create();
obj = ctxt.lookup("java:comp/env/ejb/CommitOrder");
CommitOrderHome orderHome = (CommitOrderHome)
PortableRemoteObject.narrow(obj, CommitOrderHome.class);
CommitOrder order = orderHome.create();

// Acquire the customer ID and order details;
// Now do the required workflow to place the order
int result = acct.checkStatus(customerId);
if(result != OK) {
// stop further steps
}
result = credit.checkCreditWorth(customerId, currentOrder);
if(result != OK) {
// stop further steps
}
result = appr.getApprovals(customerId, currentOrder);
if(result != OK) {
// stop further steps
}

// Everything OK; place the order
result = order.placeOrder(customerId, currentOrder);

// do further processing as required
}
}
    以上的代码显示了一个单个的客户端。如果这个应用支持多种客户端的话，必须为每一个客户端制定一种处理方法来完成工作流程。如果有一个EJB的实现流程需要改变的话，那么所有的参与这个流程的客户端都需要改变。如果不同的EJB之间的交互需要改变的话，所有的客户端都必须知道这一点，如果流程中需要增加一个新的步骤的话，所有的客户端也必须随之修改。
    这样一来，EJB和客户端之间的改变变得非常困难。客户端必须对每个EJB分开进行访问，致使网络速度变慢。同样，应用越复杂，麻烦越大。

b. 建议的解决方法
    解决这个问题的方法是，把客户端和他们使用的EJB分割开。建议适用Session Fa?ade模式。这个模式通过一个Session Bean，为一系列的EJB提供统一的接口来实现流程。事实上，当客户端只是使用这个接口来触发流程。这样，所有关于EJB实现流程所需要的改变，都和客户端无关。
    看下面这个例子。这段代码用来控制与客户相关的订单的处理方法。
// All imports required
// Exception handling not shown in the sample code

public class OrderSessionFacade implements SessionBean {

// all EJB specific methods like ejbCreate defined here
// Here is the business method that does the workflow
// required when a customer places a new order

public int placeOrder(String customerId, Details orderDetails)
throws RemoteException {
// Get reference to the required EJBs
InitialContext ctxt = new InitialContext();
Object obj = ctxt.lookup("java:comp/env/ejb/UserAccount");
UserAccountHome acctHome = (UserAccountHome)
PortableRemoteObject.narrow(obj, UserAccountHome.class);
UserAccount acct = acctHome.create();
obj = ctxt.lookup("java:comp/env/ejb/CreditCheck");
CreditCheckHome creditCheckHome = (CreditCheckHome)
PortableRemoteObject.narrow(obj, CreditCheckHome.class);
CreditCheck credit = creditCheckHome.create();
obj = ctxt.lookup("java:comp/env/ejb/Approvals");
ApprovalsHome apprHome = (ApprovalsHome)
PortableRemoteObject.narrow(obj, ApprovalsHome.class);
Approvals appr = apprHome.create();
obj = ctxt.lookup("java:comp/env/ejb/CommitOrder");
CommitOrderHome orderHome = (CommitOrderHome)
PortableRemoteObject.narrow(obj, CommitOrderHome.class);
CommitOrder order = orderHome.create();

// Now do the required workflow to place the order
int result = acct.checkStatus(customerId);
if(result != OK) {
// stop further steps
}
result = credit.checkCreditWorth(customerId, currentOrder);
if(result != OK) {
// stop further steps
}
result = appr.getApprovals(customerId, currentOrder);
if(result != OK) {
// stop further steps
}

// Everything OK; place the order
int orderId = order.placeOrder(customerId, currentOrder);

// Do other processing required

return(orderId);
}

// Implement other workflows for other order related functionalities (like
// updating an existing order, canceling an existing order etc.) in a
// similar way
}
    在模式允许的情况下，Servlet代码将很容易实现。
// all required imports
// exceptions to be caught appropriately wherever applicable

public class OrderHandlingServlet extends HttpServlet {

// all required declarations, definitions

public void init() {
// all inits required done here
}

public void doPost(HttpServletRequest request, HttpServletResponse response)
throws IOException, ServletException {
// other logic as required
// Get reference to the session facade
InitialContext ctxt = new InitialContext();
Object obj = ctxt.lookup("java:comp/env/ejb/OrderSessionFacade");
OrderSessionFacadeHome facadeHome = (OrderSessionFacadeHome)
PortableRemoteObject.narrow(obj, OrderSessionFacadeHome.class);
OrderSessionFacade facade = facadeHome.create();

// trigger the order workflow
int orderId = facade.placeOrder(customerId, currentOrder);

// do further processing as required
}
}
    就象上面显示的，客户端的逻辑变得非常简单。流程中的任何改变只要修改模式中的一处地方就可以了。客户端可以仍旧使用原来的接口，而不必做任何修改。同样，这个模式可以用来响应其他处理器的流程处理。这让你能用同样的模式来处理不同客户端的不同流程。在这个例子中，模式提供了很好的伸缩性和可维护性。

c. 要点
§ 既然这种模式不涉及到数据访问，就应该用Session Bean来实现。
§ 对于用简单接口来实现复杂EJB的子系统来说，是一个理想的选择。
§ 这个模式不适用于无流程处理的应用。
§ 这个模式可以减少客户端于EJB之间的通信和依赖。
§ 所有和EJB有关的交互，都有同一个Session Bean来控制，可以减少客户端对EJB的误用。
§ 这个模式可以使支持多类型客户端变得更容易。
§ 可以减少网络数据传递。
§ 所有的服务器端的实现细节都对客户端隐藏，在改变发生后，客户端不用重新发布。
§ 这个模式可以同样看成一个集中处理器来处理所有的安全或日志纪录。

4. Data Access Object

a. 问题
    目前为止，你看到的模型都是用来构建可伸缩的，易于维护的J2EE应用。这些模式尽可能的把应用在多个层上来实现。但是，还有一点必须强调：EJB的数据表现。它们包括象EJB这样的数据库语言。如果数据库有改变的话，相应的SQL也必须改变，而EJB也必须随之更新。
    这些常见问题就是：访问数据源的代码与EJB结合在一起，这样致使代码很难维护。看以下的代码。
An EJB that has SQL code embedded in it
// all imports required
// exceptions not handled in the sample code

public class UserAccountEJB implements EntityBean {

// All EJB methods like ejbCreate, ejbRemove go here
// Business methods start here

public UserDetails getUserDetails(String userId) {

// A simple query for this example
String query = "SELECT id, name, phone FROM userdetails WHERE name = " + userId;

InitialContext ic = new InitialContext();
datasource = (DataSource)ic.lookup("java:comp/env/jdbc/DataSource");
Connection dbConnection = datasource.getConnection();
Statement stmt = dbConnection.createStatement();
ResultSet result = stmt.executeQuery(queryStr);

// other processing like creation of UserDetails object

result.close();
stmt.close();
dbConnection.close();
return(details);
}
}
b. 建议的解决方法
    为了解决这个问题，从而让你能很方便的修改你的数据访问。建议使用DAO模式。这个模式把数据访问逻辑从EJB中拿出来放入独立的接口中。结果是EJB保留自己的业务逻辑方法，在需要数据的时候，通过DAO来访问数据库。这样的模式，在要求修改数据访问的时候，只要更新DAO的对象就可以了。看以下的代码。
A Data Access Object that encapsulates all data resource access code
// All required imports
// Exception handling code not listed below for simplicity

public class UserAccountDAO {

private transient Connection dbConnection = null;

public UserAccountDAO() {}

public UserDetails getUserDetails(String userId) {

// A simple query for this example
String query = "SELECT id, name, phone FROM userdetails WHERE name = " + userId;

InitialContext ic = new InitialContext();
datasource = (DataSource)ic.lookup("java:comp/env/jdbc/DataSource");
Connection dbConnection = datasource.getConnection();
Statement stmt = dbConnection.createStatement();
ResultSet result = stmt.executeQuery(queryStr);

// other processing like creation of UserDetails object

result.close();
stmt.close();
dbConnection.close();
return(details);
}

// Other data access / modification methods pertaining to the UserAccountEJB
}
    现在你有了一个DAO对象，利用这个对象你可以访问数据。再看以下的代码。
An EJB that uses a DAO
// all imports required
// exceptions not handled in the sample code

public class UserAccountEJB implements EntityBean {

// All EJB methods like ejbCreate, ejbRemove go here

// Business methods start here

public UserDetails getUserDetails(String userId) {

// other processing as required
UserAccountDAO dao = new UserAccountDAO();
UserDetails details = dao.getUserDetails(userId);
// other processing as required
return(details);
}
}
    任何数据源的修改只要更新DAO就可以解决了。另外，为了支持应用能够支持多个不同的数据源类型，你可以开发多个DAO来实现，并在EJB的发布环境中指定这些数据源类型。在一般情况下，EJB可以通过一个Factory对象来得到DAO。用这种方法实现的应用，可以很容易的改变它的数据源类型。

c. 要点
§ 这个模式分离了业务逻辑和数据访问逻辑。
§ 这种模式特别适用于BMP。过一段时间，这种方式同样可以移植到CMP中。
§ DAOs可以在发布的时候选择数据源类型。
§ DAOs增强了应用的可伸缩性，因为数据源改变变得很容易。
§ DAOs对数据访问没有任何限制，甚至可以访问XML数据。
§ 使用这个模式将导致增加一些额外的对象，并在一定程度上增加应用的复杂性。

We explore this in more detail in Chapter 5, in the section "What Is a Pattern?" on page 118.

This well-known pattern definition comes from Christopher Alexander in A Pattern Language [Alex2]:

Each pattern is a three-part rule, which expresses a relation between a certain context, a problem, and a solution.

—Christopher Alexander

Alexander expands his definition further, and noted patterns figure Richard Gabriel [Gabriel] discusses this definition in more detail [Hillside]. Gabriel offers his own version of Alexander's definition as applied to software:

Each pattern is a three-part rule, which expresses a relation between a certain context, a certain system of forces which occurs repeatedly in that context, and a certain software configuration which allows these forces to resolve themselves. [See A Timeless Way of Hacking.]

—Richard Gabriel

This is a fairly rigorous definition, but there are also much looser ones. For example, Martin Fowler offers the following definition in Analysis Patterns [Fowler2]:

A pattern is an idea that has been useful in one practical context and will probably be useful in others.

—Martin Fowler

As you can see, there are many definitions for a pattern, but all these definitions have a common theme relating to the recurrence of a problem/solution pair in a particular context.

Some of the common characteristics of patterns are as follows:

• Patterns are observed through experience.

• Patterns are typically written in a structured format (see "Pattern Template" on page 129).

• Patterns prevent reinventing the wheel.

• Patterns exist at different levels of abstraction.

• Patterns undergo continuous improvement.

• Patterns are reusable artifacts.

• Patterns communicate designs and best practices.

• Patterns can be used together to solve a larger problem.

Many great minds have spent a significant amount of time attempting to define and refine the notion of a software pattern. Suffice it to say, we do not presume to be great minds, nor do we wish to spend time expanding these discussions. Instead, we attempt to be true to aspects of these various definitions, focusing on the most simple and recurring theme in each.
                                                                                                               ---------------from Core J2ee Patterns