面向對象程序設計比任何具體技術(shù)都重要。但是在使用種種模式的時(shí)候，也要防止
過(guò)度設計，增加不必要的復雜性、浪費時(shí)間和經(jīng)費。
1、使用接口降低程序的耦合性（Achieving Loose Coupling with Interfaces）
雖然面向接口編程回比直接面向具體類(lèi)編程增加一點(diǎn)點(diǎn)的復雜性，但是帶來(lái)的好處卻是巨大的。
1）、可以改變實(shí)現而不改變調用的代碼。這使我們可以重新實(shí)現程序的一部分，而不用去修改其它部分。
2）、可以自由的實(shí)現接口，并促進(jìn)重用。
3）、必要的時(shí)候可以寫(xiě)出一個(gè)簡(jiǎn)單的測試實(shí)現，或者Stub實(shí)現。
2、盡量使用結合，而不是繼承(Prefer Object Composition to Concrete Inheritance)
結合提供了更大的靈活性，它可以在運行時(shí)改變程序的行為。Strategy和State模式都是基于這一理論的。
3、模版模式(The Template Method Design Pattern)
模版模式是直接類(lèi)繼承的一種正確使用。但你知道一些算法的步驟，但是不清楚他們的具體操作就可以使用模版模式，將具體的操作留到以后實(shí)現。依賴(lài)倒轉 (IOC/Inversion of Control)就是模版模式的一種使用，它通過(guò)模版模式，讓框架代碼調用用戶(hù)自己的代碼，而不是正常的那種用戶(hù)代碼去掉用框架的代碼。模版模式特別適用 于框架設計。
4、策略模式(The Strategy Design Pattern)
策略模式比模版模式稍微復雜了一點(diǎn)，但是提供了更大的靈活性。但存在以下的情況時(shí)就應該使用策略模式：
1）、當算法的所有的步驟都可變，而不是僅僅有幾個(gè)的時(shí)候
2）、當實(shí)現具體步驟的類(lèi)有一個(gè)特定的繼承層次的時(shí)候
3）、當實(shí)現具體步驟的類(lèi)需要和其他類(lèi)相關(guān)聯(lián)的時(shí)候
4）、當這些步驟需要在運行時(shí)改變的時(shí)候
5）、當算法特定步驟的實(shí)現會(huì )持續增加的時(shí)候
5、使用回調增加擴展性(Using Callbacks to Achieve Extensibility)
回調是策略模式的一種特殊使用，他可以實(shí)現特殊的操作，而將錯誤處理、Logging放進(jìn)框架中。如：
public interface RowCallbackHandler {void processRow(ResultSet rs) throws SQLException;}
public void query(String sql, RowCallbackHandler callbackHandler)
throws JdbcSqlException {
try {
.....
while (rs.next()) {
callbackHandler.processRow(rs);
}
....
} catch (SQLException ex) {
....
} finally {
....
}
}
回調的優(yōu)點(diǎn)：
1）、可以集中進(jìn)行錯誤處理和資源的獲取、釋放。這樣可以讓你實(shí)現更靈活、更強大的錯誤處理，還不增加工作量。
2）、于底層實(shí)現細節無(wú)關(guān)。
3）、一個(gè)工作流程，可以通過(guò)不同的實(shí)現，完成不同的工作。充分實(shí)現了代碼的重用。
回調的缺點(diǎn)：
1）、這種模式，不能讓你直接看到被調用的代碼。這可能讓代碼變得不容易理解和維護。
2）、必須創(chuàng )建一個(gè)回調的接受接口或類(lèi)。
3）、不知道書(shū)上再寫(xiě)什么。
這個(gè)模式特別適用于回調接口非常簡(jiǎn)單的情況，最好回調接口只有一個(gè)方法，這樣可以通過(guò)inner類(lèi)的形式實(shí)現。
6、觀(guān)察者模式（The Observer Desing Pattern）
只有當系統中出現了需要了解工作流程的松散監聽(tīng)者（Loosely coupled Listener）時(shí)，才需要使用這種模式。如果我們過(guò)度的使用了他，就會(huì )導致業(yè)務(wù)被事件（event）發(fā)布的代碼所淹沒(méi)。只有重要的工作流程才有可能需 要實(shí)現他。監聽(tīng)者（Listener）必須能夠快速的返回，并且線(xiàn)程安全。不能及時(shí)放回的監聽(tīng)者可能阻塞這個(gè)程序。
七、完善方法的參數（Consider Consolidating Method Parameters）
有些時(shí)候，我們需要將多個(gè)方法參數壓縮到一個(gè)對象中，這樣可以簡(jiǎn)化代碼。最大的好處就是可以改變方法的參數，但是不用改變調用的代碼，并且能過(guò)簡(jiǎn)單的實(shí)現方法的默認參數。缺點(diǎn)就是可能參數大量的小對象，這些對象將消耗堆的空間。
八、異常捕捉（Exception Handling – Checked or Unchecked Exceptions）
Java將異常分為：Checked exceptions,Unchecked(Runtime) exceptoins。Checked exceptions繼承與java.lang.Exception，不許聲明和捕捉；Runtime exceptions繼承與java.lang.RuntimeException，不用生命，可以不捕捉。（C++,C#中的異常都相當于 Unchecked Exceptions）
雖然傳統的觀(guān)點(diǎn)認為盡量使用Checked Exception，不用Runtime Exception。但是作者不怎么認為，理由如下：
1）、太多代碼
2）、難于閱讀
3）、無(wú)休止的包裝Exception
4)、易變得方法聲明
5）、導致不必要的關(guān)聯(lián)底層實(shí)現。
作者相信，當一個(gè)函數返回兩個(gè)可選返回值得一個(gè)的時(shí)候，就需要去判斷，最好編譯器能過(guò)強制判斷。那就是使用Checked Exception，其他的情況，作者認為Checked Exception被過(guò)分強調了。
注：Checked異常要比使用return codes強，它能夠強迫用戶(hù)去捕捉異常。但是Checked Exception不適合用于表示致命的錯誤，和調用者不需要去捕捉的異常。J2ee容器有責任去捕捉并記錄Runtime Exception。
每當需要決定使用哪一種異常的時(shí)候，都需要問(wèn)自己下面的幾個(gè)問(wèn)題：
1）、所用調用者都需要處理這個(gè)錯誤嗎？是否異常是作為方法的另一種返回值。
例子：processInvoice()
回答：使用Checked Exception，讓編譯器幫組我們做檢查。
2）、只有少數調用者需要處理這個(gè)錯誤嗎？
例子：JDO exceptinos
回答：使用Runtime Exception。讓用戶(hù)可以捕捉，也可以不捕捉。
3）、是非常嚴重的異常嗎？是不能恢復的異常嗎？
例子：因連接不上數據庫，導致的業(yè)務(wù)異常
回答：使用Runtime Exception。調用者除了通知用戶(hù)，不能做任何其他有用的事情。
4）、還不清楚？
回答：使用Runtime Exception。讓調用者自己決定是否捕捉。
注：使用Runtime Exception時(shí)，最好也聲明異常。
良好的異常捕捉實(shí)踐：保存原始異常，重寫(xiě)getMessage()和printStackTrace()方法。
讓異常包含更多信息：
1）、如果程序需要針對不同的異常作出相應的反應，就需要定義一系列實(shí)現統一個(gè)接口的異常，在每個(gè)類(lèi)中作特殊的處理。
2）、針對用戶(hù)的異常，最好定義一個(gè)getErrorCode()的方法，將實(shí)際的異常消息放在properties中，這樣方便以后的處理。
3）、異常信息必須盡可能的詳細！[WebApplicationContext failed to load config]就不是一個(gè)很好的消息，這個(gè)消息應該寫(xiě)成[WebApplicationContext failed to load config from file /WEB-INF/applicationContext.xml‘: cannot instantiate class ‘com.foo.bar.Magic’ attempting to load bean element with name ‘too’ – check that this class has a public no arg constructor]。難度好像的確很大。
九、使用反射（Using Reflection）
反射可以讓程序在運行時(shí)加載、實(shí)例化、操作類(lèi)。反射還可以強化很多設計模式，比如工廠(chǎng)模式(Factory)，就沒(méi)有必要將類(lèi)名寫(xiě)在程序中，可以直接配置到文件中。
反射和Swithches(Reflection and Switches)
public void vetoableChange(PropertyChangeEvent e) throws PropertyVetoException {
if (e.getPropertyName() .equals ("email")) {
String email = (String) e.getNewValue();
validateEmail (email, e);
}
...
} else if (e.getPropertyName() .equals ("age")) {
int age = ((Integer) e.getNewValue()).intValue();
validateAge(age, e);
}
...
}
是一個(gè)正常的屬性檢查的代碼，但是如果我們需要增加或者刪除一個(gè)屬性，我們就需要修改這些判斷，這意味著(zhù)我們需要重新測試。但是如果我們使用反射，就可以非常優(yōu)雅的解決怎么問(wèn)題
public AbstractVetoableChangeListener() throws SecurityException {
Method[] methods = getClass() .getMethods();
for (int i = 0; i < methods.length; i++) {
if (methods[i] .getName() .startsWith(VALIDATE_METHOD_PREFIX) &&
methods[i] .getParameterTypes() .length == 2 &&
PropertyChangeEvent.class.isAssignableFrom(methods[i].
getParameterTypes() [1])) {
// We‘ve found a potential validator
Class[] exceptions = methods[i] .getExceptionTypes();
// We don‘t care about the return type, but we must ensure that
// the method throws only one checked exception, PropertyVetoException
if (exceptions.length == 1 &&
PropertyVetoException.class.isAssignableFrom(exceptions[0])) {
// We have a valid validator method
// Ensure it‘s accessible (for example, it might be a method on an
// inner class)
methods[i].setAccessible(true);
String propertyName = Introspector.decapitalize(methods[i].getName().
substring(VALIDATE_METHOD_PREFIX.length()));
validationMethodHash.put(propertyName, methods[i]);
System.out.println(methods[i] + " is validator for property " +
propertyName);
}
}
}
}
public final void vetoableChange(PropertyChangeEvent e)
throws PropertyVetoException {
Method m = (Method) validationMethodHash.get(e.getPropertyName());
if (m != null) {
try {
Object val = e.getNewValue();
m.invoke(this, new Object[] { val, e });
} catch (IllegalAccessException ex) {
System.out.println("WARNING: can‘t validate. " +
"Validation method "‘ + m + "‘ isn‘t accessible");
} catch (InvocationTargetException ex) {
// We don‘t need to catch runtime exceptions
if (ex.getTargetException() instanceof RuntimeException)
throw (RuntimeException) ex.getTargetException();
// Must be a PropertyVetoException if it‘s a checked exception
PropertyVetoException pex = (PropertyVetoException)
ex.getTargetException();
throw pex;
}
}
}
雖然，使用反射的代碼要比正常的代碼復雜了一點(diǎn)，但是他只需要測試一遍，就可以應對可能的修改，這樣才能說(shuō)是框架性的代碼！反射是Java的核心API，所以必須掌握。
反射和工廠(chǎng)模式（Reflection and the Factory Design Pattern）
public Object getObject(String classname, Class requiredType)
throws FactoryException {
try {
Class clazz = Class.forName(classname);
Object o = clazz.newInstance();
if (! requiredType.isAssignableFrom(clazz))
throw new FactoryException("Class "‘ + classname +
"‘ not of required type " + requiredType);
// Configure the object...
return o;
} catch (ClassNotFoundException ex) {
throw new FactoryException("Couldn‘t load class "‘ + classname + ""‘, ex);
} catch (IllegalAccessException ex) {
throw new FactoryException("Couldn‘t construct class "‘ + classname + "‘: is the no arg constructor public?", ex);
} catch (InstantiationException ex) {
throw new FactoryException("Couldn‘t construct class "‘ + classname +
"‘: does it have a no arg constructor", ex);
}
}
使用： MyInterface mo = (MyInterface)
beanFactory.getObject("com.mycompany.mypackage.MyImplementation",
MyInterface.class);
使用反射時(shí)，一般都會(huì )導致我們不能確定代碼是否能夠正常被執行，這是就要求我們必須提供更詳細的錯誤信息，以方便以后的處理。
動(dòng)態(tài)代理（Java 1.3 Dynamic Proxies）
第11章（Infrastructure and Application Implementation）會(huì )詳細介紹，是一個(gè)和AOP（Aspect Oriented Programming ）相關(guān)的東西。
十、使用JavaBean取得靈活性（Using JavaBeans to Achieve Flexibility）
使用JavaBeans可以讓對象很容易的使用代碼之外的配置。不過(guò)最好能過(guò)使用下面的這些類(lèi)：
-
PropertyEditor
-
PropertyChangeListener
-
VetoableChangeListener
-
Introspector
十一、通過(guò)程序級的注冊避免單例模式（Avoid a Proliferation of Singletons by Using an Application Registry）
傳統的單例模式有很多的缺點(diǎn)，比如單例類(lèi)將被硬編碼于代碼中，單例類(lèi)必須自己配制，復雜的程序可能需要很多單例類(lèi)，單例類(lèi)不支持接口，單例類(lèi)不能被繼承，不能被及時(shí)的更新?tīng)顟B(tài)。所有的這一些都大大局限了單例類(lèi)的使用。
不過(guò)通過(guò)程序上下文（application context）可以很好的解決這些問(wèn)題，首先它可以是一個(gè)正常的Java類(lèi)，這就避免了所有上面的問(wèn)題。他只要在程序初始化時(shí)，取得然后在程序的其他地方直接使用。甚至還可以直接配置到JNDI中。
我覺(jué)得最大的優(yōu)點(diǎn)就是他的可以動(dòng)態(tài)配置性，這要比將他硬性寫(xiě)在代碼中好太多。
十二、重構（Refactoring）
重構不應該僅僅局限于代碼的重構，錯誤消息，log，文檔都應該是重構的對象。
