隨筆檔案

http://www-128.ibm.com/developerworks/cn/opensource/os-ecl-ajax/index.html?S_TACT=105AGX52&S_CMP=techcsdn http://www.sergiopereira.com/articles/prototype.js.html http://blog.csdn.net/calvinxiu/archive/2006/08/08/1036306.aspx http://java.csdn.net/n/20060807/93375.html http://java.csdn.net/n/20060808/93473.html https://compdoc2cn.dev.java.net/prototype/html/prototype.js.cn.html 定義：一個正則表達式，就是用某種模式去匹配一類字符串的一個公式。
正則表達式由一些普通字符和一些元字符（metacharacters）組成。普通字符包括大小寫的字母和數字，而元字符則具有特殊的含義，我們下面會給予解釋。

元字符	?	描述
.		匹配任何單個字符。例如正則表達式r.t匹配這些字符串：rat、rut、r t，但是不匹配root。?
$		匹配行結束符。例如正則表達式weasel$ 能夠匹配字符串"He's a weasel"的末尾，但是不能匹配字符串"They are a bunch of weasels."。?
^		匹配一行的開始。例如正則表達式^When in能夠匹配字符串"When in the course of human events"的開始，但是不能匹配"What and When in the"。
*		匹配0或多個正好在它之前的那個字符。例如正則表達式.*意味著能夠匹配任意數量的任何字符。
\		這是引用府，用來將這里列出的這些元字符當作普通的字符來進行匹配。例如正則表達式\$被用來匹配美元符號，而不是行尾，類似的，正則表達式\.用來匹配點字符，而不是任何字符的通配符。
[ ]? [c1-c2] [^c1-c2]		匹配括號中的任何一個字符。例如正則表達式r[aou]t匹配rat、rot和rut，但是不匹配ret。可以在括號中使用連字符-來指定字符的區間，例如正則表達式[0-9]可以匹配任何數字字符；還可以制定多個區間，例如正則表達式[A-Za-z]可以匹配任何大小寫字母。另一個重要的用法是“排除”，要想匹配除了指定區間之外的字符——也就是所謂的補集——在左邊的括號和第一個字符之間使用^字符，例如正則表達式[^269A-Z] 將匹配除了2、6、9和所有大寫字母之外的任何字符。
\< \>		匹配詞（word）的開始（\<）和結束（\>）。例如正則表達式\<the能夠匹配字符串"for the wise"中的"the"，但是不能匹配字符串"otherwise"中的"the"。注意：這個元字符不是所有的軟件都支持的。
\( \)		將 \( 和 \) 之間的表達式定義為“組”（group），并且將匹配這個表達式的字符保存到一個臨時區域（一個正則表達式中最多可以保存9個），它們可以用 \1 到\9 的符號來引用。
|		將兩個匹配條件進行邏輯“或”（Or）運算。例如正則表達式(him|her) 匹配"it belongs to him"和"it belongs to her"，但是不能匹配"it belongs to them."。注意：這個元字符不是所有的軟件都支持的。
+		匹配1或多個正好在它之前的那個字符。例如正則表達式9+匹配9、99、999等。注意：這個元字符不是所有的軟件都支持的。
?		匹配0或1個正好在它之前的那個字符。注意：這個元字符不是所有的軟件都支持的。
\{i\} \{i,j\}		匹配指定數目的字符，這些字符是在它之前的表達式定義的。例如正則表達式A[0-9]\{3\} 能夠匹配字符"A"后面跟著正好3個數字字符的串，例如A123、A348等，但是不匹配A1234。而正則表達式[0-9]\{4,6\} 匹配連續的任意4個、5個或者6個數字字符。注意：這個元字符不是所有的軟件都支持的。

---

public aspect TraceAspect{
   private Logger _logger = Logger.getLogger("trace");
   pointcut traceMethods(): execution(* *.*(..))&&!within(TraceAsptect);
   before() : traceMethods(){
      Signature sig = thisJoinPointStaticPart.getSignature();
      _logger.logp(Level.INFO, sig.getDeclaringType().getName(), sig.getName(), "Entering");
  }
}

What’s wrong with conventional logging ?

When a new module is added to the system, all of its methods that need logging must be instrumented. Such instrumentation is invasive, causing the tangling of the core concerns with the logging concern. Further, if you ever happen to change the logging toolkit to a different API, you need to revisit every logging statement and modify it.

Consistency is the single most important requirement of logging. It means that if the logging specification requires that certain kinds of operations be logged, then the implementation must log every invocation of those operations. When things go wrong in a system, doubting the logging consistency is probably the last thing you want to do. Missed logging calls can make output hard to understand and sometimes useless. Achieving consistency using conventional logging is a lofty goal, and while systems can attain it initially, it requires continuing vigilance to keep it so. For example, if you add new classes to the system or new methods in existing classes, you must ensure that they implement logging that matches the current logging strategy.

The beauty of AspectJ-based logging

The limitations are not a result of the logging APIs or their implementations; rather, they stem from the fundamental limitations of objectoriented programming, which require embedding the logging invocations in each module. AOP and AspectJ overcome those limitations. AspectJ easily implements the invocation of logging statements from all the log points. The beauty is that you do not need to actually instrument any log points; writing an aspect does it automatically. Further, since there is a central place to control logging operations, you achieve consistency easily.

The most fundamental difference between conventional logging and AspectJbased logging is modularization of the logging concern. Instead of writing modules that implement core concepts in addition to invoking logging operations, with AspectJ you write a few aspects that advise the execution of the operations in the core modules to perform the logging. That way, the core modules do not carry any logging-related code. By modularizing, you separate the logging concern
from the core concerns.

With AspectJ-based logging, the logger aspect separates the core modules and the logger object. Instead of the core modules’ embedding the log() method invocations in their source code, the logger aspect weaves the logging invocations into the core modules when they are needed. AspectJ-based logging reverses the dependency between the core modules and the logger; it is the aspect that encodes how the operations in the core modules are logged instead
of each core module deciding for itself.
 

泛型的引入使得 Java 語言中的類型系統更加復雜。以前，該語言具有兩種類型 —— 引用類型和基本類型。對于引用類型，類型 和類 的概念基本上可以互換，術語子類型 和子類 也可以互換。

隨著泛型的引入，類型和類之間的關系變得更加復雜。List<Integer> 和 List<Object> 是不同的類型，但是卻是相同的類。盡管 Integer 擴展 Object，但是 List<Integer> 不是 List<Object>，并且不能賦給 List<Object> 或者強制轉換成 List<Object>。

另一方面，現在有了一個新的古怪的類型叫做 List<?>，它是 List<Integer> 和 List<Object> 的父類。并且有一個更加古怪的 List<? extends Number>。類型層次的結構和形狀也變得復雜得多。類型和類不再幾乎是相同的東西了。

extends 的新含意 

在 Java 語言引入泛型之前，extends 關鍵字總是意味著創建一個新的繼承自另一個類或接口的類或接口。

引入泛型之后，extends 關鍵字有了另一個含意。將 extends 用在類型參數的定義中（Collection<T extends Number>）或者通配符類型參數中（Collection<? extends Number>）。

當使用 extends 來指示類型參數限制時，不需要子類-父類關系，只需要子類型-父類型關系。還要記住，有限制類型不需要是該限制的嚴格子類型；也可以是 該限制。換句話說，對于 Collection<? extends Number>，您可以賦給它 Collection<Number>（盡管 Number 不是 Number 的嚴格子類型）和 Collection<Integer>、Collection<Long>、Collection<Float> 等等。

在任何這些含意中，extends 右邊的類型都可以是參數化類型（Set<V> extends Collection<V>）。

Eclipse 運行命令行參數大全  
  包括英文版本和中文版本兩種的說明, 特別需要值得一提的是那個 -nl 參數, 可以指定程序啟動時所使用的語言. 例如:
eclipse -nl en_US
將啟動英文語言, 這個特性在安裝了國際化語言包以后特別有用, 可以方便的切換各個語言的版本. 注意 IBM WSAD v5.1 也支持這個功能. 

運行 Eclipse
將 Eclipse 驅動程序安裝（解壓縮）到某個目錄（例如，c:\eclipse）中之后，通過運行頂級安裝目錄中的 Eclipse 可執行文件來啟動"工作臺"。在 Windows 系統上，該可執行文件稱為 eclipse.exe，而在 Linux 系統上稱為 eclipse。注意：下列討論描述 Windows 系統上的設置。Linux 上的設置是相似的。

如果您沒有另行指定，則平臺將缺省工作區目錄創建為可執行文件的兄弟目錄（例如 c:\eclipse\workspace）。此工作區目錄用作項目的缺省內容區，還用于保存任何必需的元數據。要進行共享安裝或多工作區安裝，應明確指出工作區的位置而不是使用缺省值。有兩種控制工作區位置的方法：使用當前工作目錄或使用 -data 命令行自變量。

將工作區位置設置為在當前工作目錄內
在此方案中，工作區位置將是當前工作目錄中稱為 workspace 的目錄。

實現此目的最容易的方法可能是使用下列步驟來創建快捷方式：

導航到 Windows 資源管理器中的 eclipse.exe 并使用右鍵拖動來創建 eclipse.exe 的快捷方式。 
編輯快捷方式的屬性，以使啟動位置：字段標識工作區位置的父目錄（例如，c:\users\robert）。 
關閉屬性對話框并雙擊快捷方式（如果提供的目錄為 c:\users\robert，則工作區位置將為 c:\users\robert\workspace）。 
當然，您也可以使用命令提示符（通過將目錄切換為工作區父目錄然后運行 eclipse.exe）來獲得同樣的效果。

使用 -data 設置工作區的特定位置
要使用 -data 命令行自變量，只要將 -data your_workspace_location（例如，-data c:\users\robert\myworkspace）添加至快捷方式屬性中的目標字段或顯式地將它包括在命令行上。

使用 -vm 設置 java VM
建議顯式指定在運行 Eclipse 時要使用哪個 Java VM。使用 -vm 命令行自變量（例如，-vm c:\jre\bin\javaw.exe）可以實現此目的。如果不使用 -vm，則 Eclipse 將使用在 O/S 路徑上找到的一個 Java VM。當安裝其它產品時，它們可更改您的路徑，導致在下一次啟動 Eclipse 時使用另一 Java VM。

運行 Eclipse 中的高級主題
Eclipse 可執行文件及平臺本身提供了人們感興趣的開發或調試 Eclipse 各部件的許多執行選項。運行 Eclipse 可執行文件的一般格式是：

eclipse [platform options] [-vmargs [Java VM arguments]]
Eclipse 啟動參數  命令 描述  原因 
-arch architecture
 定義 Eclipse 平臺在其上運行的處理器體系結構。Eclipse 平臺通常使用 Java os.arch 屬性的常用值來計算最佳設置。如果在此處指定該項，則這是 Eclipse 平臺使用的值。此處指定的值可作為 BootLoader.getOSArch() 用于插件。示例值有："x86"、"sparc"、"PA-RISC"和"ppc"。 2.0 
-application applicationId
 要運行的應用程序。應用程序由向 org.eclipse.core.runtime.applications 擴展點提供擴展的插件來聲明。通常不需要此自變量。如果指定了此項，則該值會覆蓋配置提供的值。如果不指定此項，則會運行"Eclipse 工作臺"。 1.0 
-boot bootJarURL
 （建議不使用；用 -configuration 代替；支持 1.0 兼容）。Eclipse 平臺的引導插件代碼（boot.jar）的位置，表示為 URL。如果指定此項，則會用它來為裝入 Eclipse 平臺引導程序類裝入器的類裝入器設置類路徑。僅當更改 startup.jar 和 boot.jar 的相對位置時才需要它。注意，不允許使用相對 URL。  *1.0 
-classloaderproperties [file]
 如果指定的話，則使用給定位置處的類裝入器屬性文件來激活平臺類類裝入器增強。文件自變量可以是文件路徑或 URL。注意，不允許使用相對 URL。單擊此處以獲得更多詳細信息。 2.0.2 
-configuration configurationFileURL
 Eclipse 平臺配置文件的位置，表示為 URL。配置文件確定 Eclipse 平臺、可用插件集和主要功能部件的位置。注意，不允許使用相對 URL。當安裝或更新 Eclipse 平臺時配置文件被寫至此位置。  2.0 
-consolelog
 將 Eclipse 平臺的錯誤日志鏡像到用來運行 Eclipse 的控制臺。與 -debug 組合時很方便使用。 1.0 
-data workspacePath
 要運行 Eclipse 平臺的工作區的路徑。工作區位置也是項目的缺省位置。相對于從中啟動 eclipse 的目錄來解釋相對路徑。 1.0 
-debug [optionsFile]
 將平臺置于調試方式，并從給定位置處的文件裝入調試選項（如果指定的話）。此文件指示哪些調試點可用于插件以及是否已啟用它們。如果未給出文件位置，則平臺在啟動 eclipse 的目錄中查找稱為".options"的文件。URL 和文件系統路徑都可作為文件位置。 1.0 
-dev [classpathEntries]
 將平臺置于開發方式。將可選類路徑條目（用逗號分隔的列表）添加至每個插件的運行時類路徑。例如，當工作區包含要開發的插件時，指定 -dev bin 會為每個插件項目的名為 bin 的目錄添加類路徑條目，允許在其中存儲最新生成的類文件。除去了冗余或不存在的類路徑條目。 1.0 
-endsplash params
 用于在 Eclipse 平臺啟動并運行時關閉閃屏的內部選項。此選項在閃屏處理鏈中不同的位置有不同的語法和語義。 2.0 
-feature featureId
 主要功能部件的標識。主要功能部件為 Eclipse 的已啟動實例提供了產品個性，并確定使用的產品定制信息。 2.0 
-keyring keyringFilePath
 磁盤上授權數據庫（或"密鑰環"文件）的位置。此自變量必須與 -password 選項配合使用。相對于從中啟動 eclipse 的目錄來解釋相對路徑。 1.0 
-nl locale
 定義 Eclipse 平臺在其上運行的語言環境的名稱。Eclipse 平臺通常自動計算最佳設置。如果在此處指定該項，則這是 Eclipse 平臺使用的值。此處指定的值可作為 BootLoader.getNL() 用于插件。示例值有："en_US"和"fr_FR_EURO"。 2.0 
-nolazyregistrycacheloading
 取消激活裝入優化的平臺插件注冊表高速緩存。缺省情況下，僅當需要時才從注冊表高速緩存（可用時）中裝入擴展的配置元素，以減少內存占用。此選項將在啟動時強制完全裝入注冊表高速緩存。 2.1 
-noregistrycache
 繞過讀寫內部插件注冊表高速緩存文件。 2.0 
-nosplash
 運行平臺而不顯示閃屏。 1.0 
-os operatingSystem
 定義 Eclipse 平臺在其上運行的操作系統。Eclipse 平臺通常使用 Java os.name 屬性的常用值來計算最佳設置。如果在此處指定該項，則這是 Eclipse 平臺使用的值。此處指定的值可作為 BootLoader.getOS() 用于插件，并用于解析插件清單文件中提及的路徑中 $os$ 變量的出現。示例值有："win32"、"linux"、"hpux"、"solaris"和"aix"。 1.0 
-password password
 授權數據庫的密碼。與 -keyring 選項配合使用。 1.0 
-perspective perspectiveId
 啟動時要在活動工作臺窗口中打開的透視圖。如果沒有指定該參數，則將打開關閉時活動的透視圖。 1.0 
-plugincustomization   propertiesFile
 包含插件首選項缺省設置的屬性文件的位置。這些缺省設置覆蓋在主要功能部件中指定的缺省設置。相對于從中啟動 eclipse 的目錄來解釋相對路徑。 2.0 
-plugins pluginsFileURL
 （建議不使用；用 -configuration 代替；支持 1.0 兼容）。 指定 Eclipse 平臺查找插件的文件的位置，表示為 URL。該文件為屬性文件格式，其中鍵是任意用戶定義名稱，值是指向 plugin.xml 文件的顯式路徑或指向包含插件的目錄的路徑的用逗號分隔的列表。注意，不允許使用相對 URL。如果指定此項，則此選項會導致創建適當的臨時配置。 *1.0 
-refresh 
 啟動時執行工作區的全局刷新的選項。這將使從上次平臺運行以來在文件系統中所做的任何更改一致。 1.0 
-showlocation 
 用于在窗口標題欄中顯示工作區的位置的選項。在發行版 2.0 中，此選項僅與 -data 命令行自變量一起使用。 2.0 
-showsplash params
 用于顯示閃屏（由可執行的 Eclipse 平臺啟動器執行）的內部選項。此選項在閃屏處理鏈中不同的位置有不同的語法和語義。 2.0 
-vm vmPath
 要用來運行 Eclipse 平臺的"Java 運行時環境"（JRE）的位置。如果不指定此項，則 JRE 位于 jre（它是 Eclipse 可執行文件的兄弟目錄）。相對于從中啟動 eclipse 的目錄來解釋相對路徑。 1.0 
-ws windowSystem
 定義 Eclipse 平臺在其上運行的 Windows 系統。Eclipse 平臺通常使用 Java os.name 屬性的常用值來計算最佳設置。如果在此處指定該項，則這是 Eclipse 平臺使用的值。此處指定的值可作為 BootLoader.getWS() 用于插件、用于配置 SWT 以及用于解析插件清單文件中提及的路徑中 $ws$ 變量的出現。示例值有："win32"、"motif"和"gtk"。 1.0 

將 -vmargs 條目后面的所有自變量（但不包括 -vmargs）作為虛擬機自變量（即，在要運行的類的前面）直接傳遞到所指示的 Java VM。注意：如果 Eclipse 啟動在 Java vm 自變量（-vmargs）之后提供的自變量（例如，-data），則 Eclipse 將不會啟動并且您將接收到"JVM 已終止。出口代碼為 1"的錯誤。

在不同的 VM 上運行 
在 J9 上運行 Eclipse
當在 J9 版本 1.5 上運行 Eclipse 時，建議使用以下 VM 選項： 

eclipse.exe [eclipse arguments] -vm path_to_j9w.exe             -vmargs -ms:32 -mm:2048 -mo:32768 -moi:32768 -mca:32 -mco:128 -mx:2000000
當在 J9 版本 2.0 上運行 Eclipse 時，J9W 選擇的缺省自變量應為合適的選項。但是，要覆蓋 Eclipse 可執行文件以內部方式自動設置的參數，必須指定 -vmargs 不帶任何參數，如下所示： 

eclipse.exe [eclipse arguments] -vm path_to_j9w.exe -vmargs
有關進一步信息，參考 J9 VM 文檔和幫助。

在 IBM Developer Kit, Java(TM) Technology Edition VM 上運行 Eclipse
IBM Developer Kit, Java(TM) Technology Edition 1.3 Linux 的缺省 VM 設置適合進行初期研究工作，但在進行大型開發時是不夠的。對于大型開發，應修改 VM 自變量以使有更多的堆可用。例如，下列設置將允許 Java 堆增大為 256MB：
愛因斯坦曾經說：“任何事情都應該越簡單越好，而不是比較簡單。”實際上，科學真理的目的就是在假設的前提下去簡化一個理論，這樣，人們可以去關注真正重要的問題。在企業軟件開發中，道理是一樣的。
　　簡化企業軟件開發的一個關鍵是，提供一個這樣的應用框架：它可以使開發人員不用關注于很多復雜的問題，比如事務處理、安全和持久化等。一個設計良好的框架將提升代碼的可復用性，提高開發者的效率，并得到更高質量的軟件。然而，目前J2EE 1.4下的EJB 2.1 框架被廣泛認為是設計較差而且過度復雜的。不滿足于EJB2.1框架，JAVA開發者使用了很多其他的中間件服務產品。最值得關注的是，以下兩個框架吸引了大量開發者的興趣和積極反饋。這兩個框架很可能成為未來企業JAVA應用開發框架的選擇。
　　Spring框架是一個廣受歡迎的但是非標準的開源框架。它主要由Interface21公司開發和控制。Spring框架的體系結構是基于注射依賴（DI）模式。Spring框架使用了大量的XML配置文件，它可以獨立應用，或者在現有的應用服務器上工作。
　　EJB 3.0框架是JCP定義的并且被所有主流J2EE提供商支持的標準框架。EJB 3.0規范的預發布版本目前已經有開源的和商業的實現，如JBOSS和ORACLE。EJB 3.0大量使用了JAVA注解（Java annotations，是JDK1.5提供的新功能。譯者注）
　　這兩個框架有著一個共同的核心設計理念：它們的目標是為松耦合的POJO類提供中間件服務。框架通過在運行時截取執行環境，或將服務對象注射給POJO類的方式，將應用服務和POJO類“連接”起來。POJO類本身并不關注如何“連接”，而且也很少依賴于框架。這樣，開發者可以將注意力集中在業務邏輯上，可以對他們的POJO類進行與框架無關的單元測試。并且，由于POJO類不需要繼承框架的類或實現框架提供的接口，開發者可以在更加靈活性的基礎上構建繼承體系，和搭建應用。
　　盡管有著共同的理念，但這兩個框架采取了不同的方式來提供POJO服務。由于已經出版了大量的比較Spring與EJB2.1或者EJB3.0與EJB2.1的書籍和文章，而沒有關于比較Spring和EJB3.0的認真研究，因此，本文將考察它們之間幾個關鍵的不同，討論他們優缺點。本文談到的主題同樣適用于其他不太有名的但同樣提供“松耦合POJO” 設計的企業中間件框架。我希望，這篇文章可以幫助你選者最合適的你需求的框架。
提供商無關性
　　開發者選擇JAVA平臺的一個最重要的原因就是它的提供廠商無關性。EJB 3.0是一個被設計為對提供商沒有依賴性的開放的標準。EJB 3.0規范由企業JAVA社區的主流開源組織和廠商共同編寫和支持的。EJB 3.0框架使開發者的應用程序實現可以獨立于應用服務器。比如，JBoss的EJB 3.0的實現是基于Hibernate的，Oracle的EJB 3.0實現是基于TopLink的，但是，在JBoss或者Oracle上跑應用程序，開發者既不需要去學習Hibernate，也不需要學習TopLink提供的獨特API。廠商無關性使EJB 3.0框架區別于當前其他任何的POJO中間件框架。
　　然而，就象很多EJB 3.0的批評者很快指出的一樣，目前EJB 3.0規范正在編寫還未完全完成最終發布版。很有可能，還需要1至2年，EJB 3.0才會被主流J2EE廠商完全接受。但是，就算你的應用服務器本身不支持EJB 3.0，你也可以通過下載和安裝一個“可嵌入的” EJB 3.0產品，來使你的應用服務器支持EJB 3.0應用。比如，JBoss“可嵌入的” EJB 3.0產品是開源的，它可以運行在任何兼容J2SE-5.0環境下（如你的應用服務器），目前處于Beta版測試中。其他廠商同樣可以快速發布他們自己的可嵌入EJB 3.0產品，特別是規范中“數據持久化”部分。
　　另一方面，Spring一直是一個非標準的技術，而且在可以預計的未來仍將如此。盡管你在任何應用服務器都上可以使用Spring框架，但基于Spring的應用仍然被限制于Spring本身和在你的應用中使用到的Spring提供的各種特別服務。
　　由于Spring框架是一個開源項目，因此，它使用的配置文件XML格式和開發接口都是私有的。當然，這種限制不僅體現在Spring框架中，其他任何非標準產品都會有這種限制。但是，你的Spring應用的長期生存能力將依賴于Spring項目本身（或者說Interface 21公司，因為它雇傭了大多數的Spring核心開發人員）。并且，如果你使用了Spring提供的特殊服務，如Spring事務管理器或者Spring MVC，你同樣被限制于Spring提供的API。
　　并且，Spring應用是知道后端服務提供者的（即應用程序是知道服務提供者的，這樣應用程序將會在一定程度上依賴于服務提供方：譯者注）。例如，對于數據持久化服務，Spring框架提供了不同的DAO和模板Helper類，用于JDBC、Hibernate,、iBatis和JDO。這樣，假如你需要改變一個Spring應用的持久化服務提供者（如，從JDBC換到Hibernate），你將需要重構你的系統應用代碼，來使用新的Helper類。
服務整合
　　Spring框架是建立在應用服務器和服務庫之上，它的服務整合代碼（如數據訪問模板和Helper類）是基于框架的，并暴露給應用開發者。相反，EJB 3.0框架是緊密整合到應用服務器中的，它的服務整合代碼是封裝在一個標準的接口下的。
　　因此，EJB 3.0廠商可以輕松的優化整體性能和開發者體驗。如，在JBoss的EJB 3.0實現中，當你通過實體管理器持久化一個實體BEAN POJO時，Hibernate session事務將在JTA事務提交時自動提交。通過使用簡單的@PersistenceContext注解（例子參看后面文章），你可以甚至可以將實體管理器和其下的Hibernate事務綁定到一個有狀態的session bean上。應用程序事務可以在一個session中跨越多個線程，在事務性的WEB應用中這是非常有用的，如多頁面的購物車。
　　基于EJB 3.0 框架、Hibernate、和JBoss 內部Tomcat的緊密整合，上面提到的簡單的整合的編程接口是可能的。Oracle的EJB 3.0框架和它內部的Toplink持久服務可以達到同樣層次的整合。
　　EJB 3.0中整合服務的另一個好例子是集群支持。假如你部署一個EJB 3.0應用到一個集群服務器，所有的故障切換、負載均衡、分布式緩存、和狀態復制服務對于應用程序來說，都是自動完成的。集群服務被隱藏在EJB 3.0編程接口之下，對于EJB 3.0開發者來說，這些服務都是完全透明的。
　　在Spring中，優化框架和服務之間交互更加困難一些。例如，想要用Spring的聲明式事務服務來管理Hibernate事務，必須在XML配置文件中明確的配置Spring的事務管理器（TransactionManager）和Hibernate SessionFactory對象。Spring應用開發者必須自己管理跨越多個HTTP請求的事務。并且，沒有簡單的方法可以在Spring應用中實現集群服務
服務聚合的靈活性
　　由于Spring中的服務整合代碼是作為編程接口暴露給應用開發者的，因此開發人員可以根據需要來聚合多個服務。這個特性使你可以集成一個你自己的“輕量”級應用服務器。Spring的一個通常的用法是將Tomcat和Hibernate連接起來來支持簡單的數據庫驅動的WEB應用程序。在這種情況下，Spring本身提供了事務管理服務，Hibernate提供了持久化服務，這種設置本身就創建了一個小型的應用服務器。
　　通常，EJB 3.0應用服務器不提供給開發者這種按照你的需要來選擇服務的靈活性。大多數情況，你會得到一系列已經預先打包好的特性，其中有些你可能是不需要的。然而，如果應用服務器提供了模塊內部的獨特設計，就象JBOSS一樣，你可以不去關心這些不必要的特性。在任何情況下，去定制一個全功能的應用服務器并不是一個瑣碎而沒有意義的工作。
　　當然，如果一個應用不是一個單一的結點，你將需要連接多個應用服務器提供的服務（如資源池、消息隊列和集群）。這種情況下，從總的資源消耗上看，Spring框架就和任何EJB 3.0方案一樣是“重量級”的。
　　為了進行容器外的單元測試，Spring的靈活的服務聚合也可以來連接假對象，來替代真的服務對象。在EJB 3.0應用中，大多數的組件都是簡單POJO，他們可以容易進行容器外的單元測試。但是，如果要測試與容器服務相關的服務對象（如持久化實體管理器），更好的方式是進行容器內的測試，因為這樣比使用假對象來替代的方式更加容易，更加健壯，而且更加準確。
XML vs. 注解
　　從應用開發者的角度來看，Spring的編程接口主要基于XML配置文件，而EJB 3.0則大量的使用了JAVA注解。XML文件可以表達復雜的關系，但是它們更加冗長而且不健壯。注解的方式很簡單明了，但是很難去表達復雜的或者繼承性的結構。
　　Spring和EJB 3.0分別選擇了XML和注解方式，這取決于框架的體系結構：由于注釋只能描述相當少的配置信息，只有一個預先整合好的框架（如大多數重要事情已經在框架中實現了）才能大量的使用注釋作為它的配置選項。象我們討論的一樣，EJB 3.0滿足了這些要求，而Spring作為一個一般的注射依賴框架，它沒有做到這一點。
　　當然，由于EJB 3.0和Spring相互學習了很多特性，所以，它們都在某種層次上支持XML和注釋。例如，EJB 3.0中可以應用XML配置文件來作為一個選擇性的機制，用來改變注釋的默認行為。注釋也可以用來配置一些Spring服務。
　　研究XML和注釋直接區別的最好的方式就是通過例子。在下面的幾節中，我們將一起看一下EJB 3.0和Spring是如何為應用程序提供關鍵服務的。
聲明式服務
　　EJB 3.0和Spring都將運行時服務（如事務管理、安全、日志、消息、和信息服務）連接給應用程序。由于這些服務同應用程序的業務邏輯并不是直接相關的，因此，它們不被應用程序本身來管理。相反，這些服務被服務容器（如EJB 3.0和Spring）以不可見的方式在運行時提供給應用程序。開發人員（或系統管理員）通過配置來告訴容器什么時候，以怎樣的方式來應用這些服務。
　　EJB 3.0通過JAVA注解的方式來配置聲明式服務，Spring則通過XML配置文件來完成。大多數情況下，EJB 3.0 的注解方式是應用這種服務的更加簡單和優美的方式。下面是一個在EJB 3.0中對一個POJO的方法使用事務管理服務的例子。
　　public class Foo {
　　    @TransactionAttribute(TransactionAttributeType.REQUIRED)
　　    public bar () {
　　      // do something ...
　　    }   
　　}
　　你可以對一段代碼聲明多個屬性，并應用多個服務。下面是一個對EJB 3.0中POJO類同時使用事務管理服務和安全服務的例子。
　　@SecurityDomain("other")
　　public class Foo {
　　    @RolesAllowed({"managers"})
　　    @TransactionAttribute(TransactionAttributeType.REQUIRED)
　　    public bar () {
　　      // do something ...
　　    }  
　　}
　　使用XML指定代碼屬性和配置聲明服務將導致冗長的和不桅頂的配置文件。下面是Spring應用中一個XML元素的例子，它用來在Foo.bar()方法上應用一個非常簡單的Hibernate事務。
<!-- Setup the transaction interceptor -->
<bean id="foo"
  class="org.springframework.transaction.interceptor.TransactionProxyFactoryBean">
    <property name="target">
        <bean class="Foo"/>
    </property>
    <property name="transactionManager">
        <ref bean="transactionManager"/>
    </property>
    <property name="transactionAttributeSource">
        <ref bean="attributeSource"/>
    </property>
</bean>
<!-- Setup the transaction manager for Hibernate -->
<bean id="transactionManager"
  class="org.springframework.orm.hibernate.HibernateTransactionManager">
    <property name="sessionFactory">
        <!-- you need to setup the sessionFactory bean in yet another XML element -->
        <ref bean="sessionFactory"/>
    </property>
</bean>
<!-- Specify which methods to apply transaction -->
<bean id="transactionAttributeSource"
class="org.springframework.transaction.interceptor.NameMatchTransactionAttributeSource">
    <property name="properties">
        <props>
            <prop key="bar">
        </props>
    </property>
</bean>
　　XML文件的復雜程度將隨著你對同一個POJO類增加的攔截器的數量程幾何增長。意識到了僅使用XML配置文件的限制性，Spring支持在JAVA源代碼中使用Apache Commons metadata來指定事物屬性。在最新的Spring 1.2中，JDK-1.5風格的注釋也被支持。為了使用事務元數據，你需要為上面例子中的AttributesTransactionAttributeSource 改變一個transactionAttributeSource bean，并且增加一個附加的對元數據攔截器的設置。
<bean id="autoproxy"
 class="org.springframework.aop.framework.autoproxy.DefaultAdvisorAutoProxyCreator"/>
<bean id="transactionAttributeSource"
  class="org.springframework.transaction.interceptor.AttributesTransactionAttributeSource"
    autowire="constructor"/>
<bean id="transactionInterceptor"
    class="org.springframework.transaction.interceptor.TransactionInterceptor"
    autowire="byType"/>
<bean id="transactionAdvisor"
    class="org.springframework.transaction.interceptor.TransactionAttributeSourceAdvisor"
    autowire="constructor"/>
<bean id="attributes"
class="org.springframework.metadata.commons.CommonsAttributes"/>
　　
　　當你有許多事務方法時，Spring元數據簡化了transactionAttributeSource元素。但是它沒有解決XML配置文件的根本問題：仍然需要冗長的、易錯的事務攔截器，事務管理器，和事務屬性。
注射依賴
　　中間件容器的一個主要優點是它們使得程序開發人員可以去構建松耦合的應用程序。服務使用者僅僅需要知道服務接口就可以使用服務。容器把具體的服務實現實例化，然后將它們提供給服務使用者。這樣，容器可以在可替換的服務實現之間進行切換，而不改變服務接口和服務使用者代碼。
　　注射依賴模式是實現松耦合應用程序的一個最好的方式。比起以前的方式，如通過JNDI進行查找或回調容器，注射依賴模式更容易使用，而且更加優美。使用注射依賴模式，框架扮演了構建服務的對象工廠角色，然后根據運行時的配置，把這些服務對象注射到應用程序的POJO類中。從程序開發人員的角度看，作為客戶端使用者的POJO在需要使用服務對象前就自動的得到了它們。
　　Spring 和 EJB 3.0都提供了大量的DI模式支持。但是，它們之間也有著根本的不同。Spring支持了通常意義上的但是復雜的基于XML配置文件的注射依賴API；EJB 3.0支持的注射大多數通用服務對象（如，EJB和容器對象）和JNDI對象，它通過簡單的JAVA注解來完成。
　　EJB 3.0的注射注解相當的簡潔易用。@Resource標簽注射大多數的通過服務對象和JNDI對象。下面的例子顯示了如何將JNDI提供的服務器缺剩數據源對象注射給一個POJO的一個字段。DefaultDS是這個數據源的JNDI名字。myDb 變量在第一次被使用前就自動被賦予了正確的值。
　　public class FooDao {
　　    @Resource (name="DefaultDS")
　　    DataSource myDb;
　　    // Use myDb to get JDBC connection to the database
　　}
　　在EJB 3.0中，注釋@Resource不僅可以直接注射給屬性變量，它也可以通過setter方法來完成注射。下面的例子將一個session上下文對象通過setter方法注射給使用者。應用程序不用顯示的調用setter方法，在任何其他方法被調用前容器將調用setter方法完成注射。
　　@Resource
　　public void setSessionContext (SessionContext ctx) {
　　    sessionCtx = ctx;
　　}
　　對于更復雜的服務對象，還有一些特殊的注射注解。例如，@EJB 注解被用來注射EJB stubs，@PersistenceContext注解被用來注射實體管理器對象，這些對象負責處理EJB 3.0實體Bean的數據訪問操作。 下面的例子給出如何將一個實體管理器注射到一個有狀態Session Bean中。@PersistenceContext注解的類型屬性描述了被注射的的實體管理器有一個擴展的事務容器：它不會隨著JTA事務管理器自動提交事務，因此它可以應用在當session中有多次操作的應用事務管理時。
　　@Stateful
　　public class FooBean implements Foo, Serializable {
　　    @PersistenceContext(
　　      type=PersistenceContextType.EXTENDED
　　    )
　　    protected EntityManager em;
　　    public Foo getFoo (Integer id) {
　　        return (Foo) em.find(Foo.class, id);
　　    }
　　}

　　EJB 3.0 規范定義了可以通過注解來被注射使用的服務器資源。但是，它不支持用戶自定義的POJO類之間的相互注射。
　　在Spring中，為了將服務對象注射到你的POJO類中，你首先需要定義一個setter方法(或有參數的構造函數) 。下面的例子演示了 POJO 類中一個Hibernate session 工廠的屬性。
　　public class FooDao {
　　    HibernateTemplate hibernateTemplate;
　　    public void setHibernateTemplate (HibernateTemplate ht) {
　　        hibernateTemplate = ht;
　　    }
　　    // Use hibernateTemplate to access data via Hibernate
　　    public Foo getFoo (Integer id) {
　　        return (Foo) hibernateTemplate.load (Foo.class, id);
　　    }
　　}
　　因此，你可以指定容器如何得到這個服務，并且在運行時通過配置文件中XML元素的連接關系把它提供給POJO。下面的例子顯示了連接一個數據源到一個Hibernate session 工廠、session 工廠到Hibernate模板對象、模板對象最后到應用程序POJO類，整個過程的XML配置。
　　Spring 代碼復雜性的部分原因是，我們需要手工的去注射Hibernate相關類，然而，EJB 3.0 實體管理器被服務器自動管理和配置。但是，這使我們返回到了這樣的討論：Spring 不象EJB 3.0 一樣，它不同服務緊密整合在一起。
<bean id="dataSource"
  class="org.springframework.jndi.JndiObjectFactoryBean">
    <property name="jndiname">
        <value>java:comp/env/jdbc/MyDataSource</value>
    </property>
</bean>
<bean id="sessionFactory"
  class="org.springframework.orm.hibernate.LocalSessionFactoryBean">
    <property name="dataSource">
        <ref bean="dataSource"/>
    </property>
</bean>
<bean id="hibernateTemplate"
  class="org.springframework.orm.hibernate.HibernateTemplate">
    <property name="sessionFactory">
        <ref bean="sessionFactory"/>
    </property>   
</bean>
<bean id="fooDao" class="FooDao">
    <property name="hibernateTemplate">
        <ref bean="hibernateTemplate"/>
    </property>
</bean>
<!-- The hibernateTemplate can be injected into more DAO objects -->
　　盡管Spring中基于XML的注射依賴比較復雜，但是它非常強大。你可以注射任何POJO到另外的POJO中，包括程序中自定義的。
　　如果你確實想在EJB 3.0應用中使用Spring的注射依賴功能，你可以將一個Spring Bean工廠類通過JNDI注射到一個EJB中。在某些EJB 3.0 應用服務器中，廠商可能會定義一些非標準的API用來注射任意的POJO類。一個很好的例子是JBoss MicroContainer，它處理了AOP依賴性，因此它是甚至比Spring 更加通用。
　　
結論
　　盡管Spring 和EJB 3.0的目標都是提供企業服務，使得POJO可以松耦合，但是它們實現的方式非常不同。在兩個框架中注射依賴模式都有大量的應用。
　　通過EJB 3.0的標準方式、大量應用的注解、還有同應用服務器緊密整合性，這些提供了更高的廠商無關性和開發人員工作效率。Spring的以XML為中心的配置文件和注射依賴的連貫使用，允許開發人員去構造更加靈活的應用系統，并且可以同時與多個應用服務提供者同時工作。
　　
感謝
　　作者感謝Stephen Chambers, Bill Burke, 和Andy Oliver 的有價值的評論.
參考
　　The Spring framework (參考CodeZoo: Spring)
EJB 3.0
JBoss EJB 3.0
Oracle Application Server EJB 3.0 Preview
Michael Juntao Yuan specializes in end-to-end enterprise solutions and is a mobile geek and avid open source supporter.

?? bsh-deployer：將BeanShell腳本部署成JBoss服務。
?? cache-invalidation-service.xml：允許借助于JMS，而實現對EJB緩存的控制。
?? client-deployer-service.xml：部署J2EE應用客戶。
?? ear-deployer.xml：部署J2EE EAR應用。
?? ejb-deployer.xml：部署J2EE EJB應用。
?? hsqldb-ds.xml：設置嵌入式Hypersonic數據庫服務，并將其作為默認數據源。
?? http-invoker.sar：通過RMI/HTTP方式訪問到MBean和EJB。
?? jboss-aop.deployer：提供AspectManagerService，并部署JBoss AOP應用。
?? jboss-hibernate.deployer：部署Hibernate存檔（HAR文件）。
?? jboss-local-jdbc.rar和jboss-xa-jdbc.rar：集成JDBC驅動的JCA資源適配器，它們分別支持DataSource和XADataSource。但是，這并沒有提供專有JCA實現。
?? jboss-ws4ee.sar：提供J2EE Web服務支持。
?? jbossjca-service.xml：JBoss JCA實現，使得在JBoss中部署JCA資源適配器成為可能。
?? jbossweb-tomcat50-sar：含有嵌入式Tomcat服務的展開SAR文件。它為JBoss提供了標準的Web容器。
?? jms：將JMS相關的服務聚集在一起，并放置在jms目錄中。
?? hsqldb-jdbc-state-service.xml：使用HSQLDB管理狀態。
?? hsqldb-jdbc2-service.xml：使用嵌入式HSQL數據庫實現緩存和持久化。它還包含了JMS實現的核心服務，即DestinationManager MBean。
?? jbossmq-destinations-service.xml：供JBoss測試套件使用的JMS Topic和Queue。
?? jbossmq-service.xml：JMS其他服務，包括攔截器配置。
?? jms-ds.xml：將JBoss消息實現作為默認JMS提供商。并且，它還提供JCA配置信息，以供集成JBoss JCA和JMS資源適配器使用。
?? jms-ra.rar：資源適配器，供JCA處理JMS連接工廠使用。
?? jbossmq-httpil.sar：提供JMS調用層，從而實現HTTP方式使用JMS。
?? jvm-il-service.xml：配置本地JMS傳輸調用層，供本地JVM使用JMS。
?? uil2-service.xml：配置JMS版本2統一調用層。這是一種可靠的、自定義的、基于Socket的傳輸方式。推薦在不同JVM間使用它。
?? jmx-console.war：JMX控制臺應用。前面討論過。
?? jmx-invoker-server.xml：為遠程訪問JMX MBean服務器提供支持。
?? mail-ra.rar：為JavaMail提供資源適配器。
?? mail-service.xml：允許應用和服務在JBoss中使用JavaMail。請注意，郵件服務器相關信息必須由用戶提供。
?? management：含有可更換管理服務的子目錄。其中，包含有改進的Web控制臺。
?? monitoring-service.xml：配置警告監聽器，比如控制臺監聽器、E_mail監聽器，等等。
?? properties-service.xml：設置JVM的全局系統屬性（由System.getProperties返回）。
?? schedule-manager-service.xml和scheduler-service.xml：定時任務服務。
?? sqlexception-service.xml：為JDBC驅動提供標識一般性SQL異常。
?? uuid-key-generator.sar：生成唯一的、基于UUID的鍵。
all配置提供了其他配置沒有提供的其他服務，用戶可以將這些服務集成到各自的服務器配置中。具體如下：
?? cluster-service.xml：群集服務，包括JGroups集成服務、HA-JNDI、有狀態會話Bean復制、CMP2緩存有效性服務。
?? deploy-hasingleton-service.xml：HASingletonDeployer MBean。用于確保群集中只有單個節點在deploy-hasingleton目錄部署了服務。
?? deploy.last/farm-service.xml：farm群集部署服務。用于確保它在所有其他服務部署之后才部署其本身。
?? ebxmlrr-service.xml：JAXR注冊服務實現。
?? iiop-service.xml：實現對CORBA、IIOP的支持。
?? jbossha-httpsession.sar：遺留的HTTP會話復制服務。
?? remoting-service.xml：還處于試驗中的下一代分離式Invoker框架。
?? snmp-adaptor.sar：將JMX通知轉換成SNMP陷阱。
?? tc5-cluster-service.xml：用于新的HTTP復制服務的TressCache配置。 目錄結構：
?? bin：含有啟動、停止以及其他系統相關腳本。在前面，本書已經討論過啟動JBoss應用服務器的run腳本。
?? client：存儲供Java客戶應用或者外部Web容器使用的配置文件和JAR文件。用戶可以使用所需要的具體存檔，或者僅僅使用jbossall-client.jar。
?? docs：含有JBoss引用的XML DTD文件（當然，還包括JBoss具體配置文件）。同時，還存在JCA（Java Connetor Architecture，Java連接器架構）實例配置文件，供設置不同數據庫的數據源使用（比如MySQL、Oracle、Postgres）。
?? lib：包含運行JBoss微內核所需的JAR文件。請注意，不要往該目錄添加用戶自身的任何JAR文件。
?? server：包含的各個子目錄都是不同的服務器配置。通過往run腳本后添加-c <config name>參數便能夠指定不同的配置。接下來，來看看default服務器配置。

      從根本上考慮，JBoss架構是由JMX MBean服務器、微內核、一套可插入式組件服務以及MBean構成的。這種架構使得，集成不同的配置變得更加簡單，并且能夠很靈活地滿足用戶的各自需求。用戶不再需要一次性運行重量級的應用服務器。同時，用戶可以刪除不再需要使用的組件（這將從很大程度上減少服務器的啟動時間），并且通過開發自己的MBean還能夠集成其他服務到JBoss中。當然，如果是運行標準J2EE應用，則不用理會這些自定義工作。用戶所需要的一切服務，JBoss發布版都包括了。

      server目錄下存在3個服務器實例配置：all、default以及minimal，它們各自提供了不同的服務集合。很顯然，如果啟動JBoss服務器時沒有指定其他配置，則將使用default配置。
       minimal：這是啟動JBoss服務器所要求的最低配置。minimal配置將啟動日志服務、JNDI服務器以及URL部署掃描器，以找到新的部署應用。對于那些不需要使用任何其他J2EE技術，而只是使用自定義服務的場合而言，則這種JMX/JBoss配置最適合。它僅僅是服務器，而不包含Web容器、不提供EJB和JMS支持。
?? default：默認配置，它含有大部分J2EE應用所需的標準服務。但是，它不含有JAXR服務、IIOP服務、或者其他任何群集服務。
?? all：提供了所有可用的服務。它包含RMI/IIOP和群集服務，default配置中沒有提供群集服務。
      用戶也可以添加自身的服務器配置。最佳做法是，拷貝最接近用戶需求的現有配置，然后修改其具體內容。比如，如果用戶不需要使用消息服務，則只需要拷貝default目錄，并重新命名為myconfig，然后刪除jms子目錄。最后，啟動myconfig配置。
      run -c myconfig

      default服務器配置目錄的具體內容：
      conf：含有指定JBoss核心服務的jboss-service.xml文件。同時，還包括核心服務的其他配置文件。
?? data：Hypersonic數據庫實例將數據存儲在此處。JBossMQ（JMS的JBoss實現）也使用它存儲消息。
?? deploy：用戶將應用代碼（JAR\WAR\EAR文件）部署在此處。同時，deploy目錄也用于熱部署服務（即，那些能夠從運行服務器動態添加或刪除的服務）和部署JCA資源適配器。因此，用戶能夠在deploy目錄看到大量的配置文件。尤其是，用戶能夠看到JMX控制臺應用（未打包的WAR文件），本書前面討論過。JBoss服務器將定期掃描該目錄，從而查找是否有組件更新或修改，從而自動完成組件的重新部署。本書后續章節將詳細闡述部署細節。
?? lib：服務器配置所需的JAR文件。用戶可以添加自身的庫文件，比如JDBC驅動，等等。
?? log：日志信息將存儲到該目錄。JBoss使用Jakarta Log4j包作為其日志功能。同時，用戶可以在應用中直接使用Log4j日志記錄功能。
?? tmp：供部署器臨時存儲未打包應用使用，也可以作為其他用途。
?? work：供Tomcat編譯JSP使用。
      其中，data、log、tmp、work目錄是JBoss創建的。如果用戶沒有啟動過JBoss服務器，則這些目錄不會被創建。
.
      2.2.1 核心服務
     當JBoss服務器啟動時，首先會啟動conf/jboss-service.xml文件指定的核心服務。

      雖然通過conf/jboss-service.xml文件能夠添加其他MBean服務，但是更好的辦法是，將單獨的配置文件放置在deploy目錄中，因為這將使得用戶的服務具有熱部署能力。
      
2.2.2 日志服務
     Log4j是JBoss使用的日志功能包。通過conf/log4j.xml文件能夠控制JBoss的日志功能。

2.2.3 安全性服務
     安全性域信息存儲在login-config.xml文件中，其包含了許多安全性域定義。各個安全性域指定了許多JAAS登陸模塊，供安全性域認證使用。當用戶需要在應用中使用安全性時，需要在JBoss特定部署描述符jboss.xml或jboss-web.xml中指定待使用的安全性域名。

2.2.4 其他服務
      deploy目錄放置的服務不是核心服務，但具有熱部署能力。用戶可以通過XML描述符文件（*-service.xml）或JBoss服務存檔（SAR）文件給出服務。SAR同時含有XML描述符和服務所要求的其他資源（比如，類、JAR庫文件以及其他存檔），而且SAR是以單個存檔文件給出的。

投資是一種追求未來貨幣增值的經濟行為。
新中國的第一張股票：1984年12月發行的上海飛樂音響公司的股票。
90年12月19日，上證交易所開業
Unlike ad hoc non-EJB architectures, it is similar to EJB architectures in being centered around a layer of managed business service objects. However, this is where the similarity ends. Instead of running inside an EJB container, business objects run inside a lightweight container. A lightweight container isn't tied to J2EE, so it can run in a web container, a stand-alone application, or even an EJB container if necessary. It also isn't tied to the Servlet API, like an MVC web framework, which is a poor choice for managing business objects. Lightweight containers have negligible startup cost and eliminate the deployment step of EJB.

Lightweight containers provide a way to manage and locate business objects. No longer is there any need for JNDI lookups, custom service locators, or Singletons: the lightweight container provides a registry of application objects.

Lightweight containers are both less invasive and more powerful than an EJB container where co-located applications are concerned.

To provide a complete solution, the lightweight container must provide enterprise services such as transaction management. Typically this will invoke AOP interception: transparently weaving in additional behavior, such as  transaction management, before and after the execution of business methods.

From the user’s perspective, the web tier is provided by an MVC framework. We can use a dedicated
web framework such as Struts or WebWork, or—in the case of Spring—a web tier that can itself be managed
by the lightweight container and provide close integration with business objects.

Business objects will be POJOs, running inside the lightweight container. They may be “advised” via AOP interception to deliver enterprise services. Unlike EJBs, they don't usually need to depend on container
APIs, meaning that they are also usable outside any container. Business objects should be accessed
exclusively through their interfaces, allowing pluggability of business objects without changing calling
code.

Data access will use a lightweight O/R mapping layer providing transparent persistence, or JDBC via a
simplifying abstraction layer if O/R mapping adds little value.


Strengths
Following are some of the advantages of using this architecture:
(1) A simple but powerful architecture.
(2) As with local EJBs or an ad hoc non-EJB solution, horizontal scalability can be achieved by clustering
web containers. The limitations to scalability, as with EJB, will be session state management,
if required, and the underlying database. (However, databases such as Oracle 9i RAC can
deliver huge horizontal scalability independent on the J2EE tier.)
(3) Compared to an ad hoc non-EJB architecture, using a lightweight container reduces rather than
increases complexity. We don't need to write any container-specific code; cumbersome lookup
code is eliminated. Yet lightweight containers are easier to learn and configure than an EJB
container.
(4) Sophisticated declarative services can be provided by a lightweight container with an AOP
capability. For example, Spring's declarative transaction management is more configurable than
EJB CMT.
(5) This architecture doesn't require an EJB container. With the Spring Framework, for example,
you can enjoy enterprise services such as declarative transaction management even in a basic
servlet engine. (Whether you need an application server normally depends on whether you
need distributed transactions, and hence, JTA.)
(6) Highly portable between application servers.
(7) Inversion of Control allows the lightweight container to “wire up” objects, meaning that the complexity
of resource and collaborator lookup is removed from application code, and application
objects don't need to depend on container APIs. Objects express their dependencies on collaborators
through ordinary Java JavaBean properties or constructor arguments, leaving the IoC
container to resolve them at runtime, eliminating any need for tedious-to-implement and hardto-
test lookups in application code.IoC provides excellent ability to manage fine-grained business objects.
(8) Business objects are easy to unit test outside an application server, and some integration testing
may even be possible by running the lightweight container from JUnit tests. This makes it easy
to practice test first development.

Weaknesses
Following are some of the disadvantages of using this architecture:
(1) Like a local EJB architecture, this architecture can't support remote clients without an additional
remoting facade. However, as with the local EJB architecture, this is easy enough to add, especially
if we use web services remoting (which is becoming more and more important). Only in
the case of RMI/IIOP remoting are remote EJBs preferable.
(2) There's currently no “standard” for lightweight containers comparable to the EJB specification.
However, as application objects are far less dependent on a lightweight container than EJBs are
on the EJB API, this isn't a major problem. Because application objects are plain Java objects,
with no API dependencies, lock-in to a particular framework is unlikely. There are no special
requirements on application code to standardize.
(3) This architecture is currently less familiar to developers than EJB architectures. This is a nontechnical
issue that can hamper its adoption. However, this is changing rapidly.

Implementation Issues
Following are some of the implementation issues you might encounter:
(1) Declarative enterprise services can be provided by POJOs using AOP, thus taking one of the best
features of EJB and applying it without most of the complexity of EJB.
(2) A good lightweight container such as Spring can provide the ability to scale down as well as up.
For example, Spring can provide declarative transaction management for a single database
using JDBC connections, without the use of JTA. Yet the same code can run unchanged in a different
Spring configuration taking advantage of JTA if necessary.
(3) A nice variation is ensuring that POJO business objects can be replaced by local EJBs without
changes in calling code. Spring provides this ability: all we need to do is create a local EJB with
a component interface that extends the business interface, if we wish to use EJB. These last two
points make this approach highly flexible, if requirements change. (This results largely from
good OO programming practice and the emphasis on interfaces.)

建立信任
及時給予肯定
出錯時調整注意力

表現管理學ABC
A=催化劑（activator）
任何引發表現的原因
B=行為（behavior）
發生的表現
C=結果（consequence）
你對所產生表現的反應

四種結果
1．沒有反應
2．表示否定
3．調整指令
4．表示肯定

調整指令的方法
●盡可能快地、清晰而不帶責備地指出錯誤
●解釋錯誤的負面影響
●如果可以，將過錯歸結于沒有清楚地解釋工作任務
●詳細地重新解釋工作任務，并確保對方已完全理解
●表達你對當事人仍然充滿信任與信心

表揚進步
發現他們越做越好，即便做得不是完全正確，也要表揚他們的進步。通過這種方法，
你就將他們推上了成功之路，并使他們可以在那里繼續前進

鯨魚哲學反應
●立即表揚別人
●具體指出他們哪些做得對，哪些做得基本正確
●與他們分享你對于他們所做工作的積極感覺
●鼓勵他們繼續好好工作

貓捉老鼠
發現別人做的錯事
鯨魚哲學
發現別人做得正確的事情

當一切進展順利的時候，
清醒點，
說點表示肯定的話！

無論什么時候，只要你批評了別人的行為或是給了對方一個否定的反饋，不管你多么
小心地去措辭，結果都會破壞或削弱你與他之間的關系。如果你不斷地這樣做，你就會徹底毀了這種關系。他們會對你失去信任并開始用同樣的方法對待你。

首先，不需要被其他人激勵而做事情的人只有企業家，他們要么擁有自己的生意，要么是為自己工作的自由職業者。他們是自覺的，而且他們的目標與整個組織的目標是聯系在一起的。事實上，他們個人的目標通常與組織的目標是相同的。其他任何人——雇員、家里的孩子，或者是海洋世界的鯨魚——被要求做的事情都是組織需要他們去做的事情，而且是那些如果讓他們自己選擇，他們可能會選擇不做的事情。

即使是鯨魚哲學反應本身也不是最終目的，它只是幫助人們實現‘發現自己做得正確的事情’這一最終目標的手段。

擁有權利是一件了不起的事情，但是不要利用它。你能夠真正讓人們做你想讓他們做的事情的惟一途徑，就是與他們建立起一種積極的、信任的關系。對人要及時肯定，這樣你就會得到積極的結果。

如今，任何新的經營舉措，不論是技術還是服務的革新，抑或是價格戰略，都會立刻被別人知曉并被
抄襲。也就是說，你僅有的、真正可競爭的空間只是你與員工的關系。如果他們信任、尊重你，并相信你制定的目標，他們就會想方設法去取悅你的顧客。一旦你擁有了這些，再加上你的一些其他優勢，比如產品質量、價格和市場營銷以及送貨上門等等，那就沒有人能夠戰勝你了。你與下屬的關系，以及下屬與顧客之間的關系，任何競爭對手都永遠無法從你這里偷走，只有這一樣東西是你惟一擁有的。

規則就是，永遠不要以為你知道可以激勵別人的東西是什么。

鯨魚哲學只有在你
真誠和誠實的時候才會奏效

一些“鯨魚哲學”反應
在工作中
對管理人員：
你在會上提出的建議十分出色。你設計的開場白是為了引起人們的注意，我果然看到A女士在你說到XX的時候，神情很振奮。你在那么短的時間內所做的一切非常有助于客戶對我們樹立信心。你的話給我們所有人都增了光。繼續好好干吧！
對一個工作團隊：
咱們這個組在融洽合作與履行責任方面都非常出色。在接任本組的領導工作期間，是你們幫助我轉換了
角色，讓我從老板變成了協調人。我更喜歡這樣的角色。希望我們這個團隊繼續好好工作。
對一個做出貢獻的個人：
我很欣賞你在報告中自創的數字分組的方式，這樣更容易看清結果。我想推薦所有人從現在開始都使用
你的方法。期待你今后想出更多的好主意。
對十幾歲的兒子：
我真高興回家看到你把車庫打掃干凈了。我原打算這個周六自己干這活兒，沒想到你提前做了。這下我
可以放松放松，干點別的了。你讓我松了口氣，巴德，非常感謝你！
對一個剛上一年級的孩子：
早上我剛叫你一遍你就起床了。當時我們都在忙著收拾東西各自上路，你知道你一叫就起幫了我多少忙
嗎？非常多！
對一個十二歲的女兒：
我非常喜歡在開車送你去運動和上課的路上跟你聊天。聽你說你和你朋友們的事情真有趣。我希望在你
成長的過程中我們還能繼續這樣的交談。
對一個學齡前兒童：
你沒用別人幫忙就自己系好了鞋帶、選好了要穿的衣服，真是棒極了！繼續努力。我真為你感到驕傲。

一些調整指令反應
在工作中
●比爾，我知道你在使用新的結算系統時遇到了麻煩，我準備讓貝蒂幫你一把。（一段時間后）干得不
錯，比爾。你交上來的報告說明你在使用這套系統方面已經成了佼佼者。如果你有什么問題盡管告訴我。
●我們希望在這個項目上，每個人的才干都可以最大限度地發揮出來，埃利森。這就是我把你派到喬治
那一組去的原因。在那里，他們會用上你所有的技術。（一段時間后）祝賀你，埃利森。我早就知道你是跟喬治那一組工作的最佳人選。我非常欣賞你的工作。
在家里
（孩子沒有好好喂寵物。）
我現在不讓你喂寵物了，去用吸塵器打掃衛生吧。我知道你喜歡做這項家務，而且房間也確實該打掃了。（一段時間后）經過你的打掃，這房子看起來真漂亮！
（孩子們正在因為看電視而吵鬧。）
為了讓每個人都滿意，我們需要為看電視制定一個計劃。（一段時間后）我真高興你們兩個能按照那天
我們在廚房里制定的計劃看電視！

 

Reflection combines with effective object-oriented design to allow programs to be more flexible. Delegation is useful because it allows an object to change behavior at runtime. This change in behavior happens when one delegate that provides one behavior is replaced with another delegate that provides a different behavior. The number of different delegates available defines the amount that this behavior can vary.
   Without reflective mechanisms, the number of delegates is limited to only the set of classes that are included in the system at comple time. Reflection increases this range of variation by allowing the system to use classes that are written later. There are several noteworthy aspects of this relationship:
     
   

public class MainApplication {
    private Properties props;

    private CustomerDatabase custDB;

    public synchronized CustomerDatabase createDBFacade() {
        if (custDB == null) {
            try {
                String dbClassName = props.getProperty("db.class",
                        "com.wci.app.StubCustomerDB");
                Class cls = Class.forName(dbClassName);
                custDB = (CustomerDatabase) cls.newInstance();
            } catch (ClassNotFoundException ex) {
                // ...
            } catch (InstantiationException ex) {
                // ...
            } catch (IllegalAccessException ex) {
                // ...
            }
        }
        return custDB;
    }
}

import java.lang.reflect.Array;
import java.lang.reflect.Field;
import java.lang.reflect.Modifier;
import java.util.IdentityHashMap;
import java.util.Map;

import org.jdom.Document;
import org.jdom.Element;

public class Driver {
    public static Document serializeObject(Object source) throws Exception {
        return serializeHelper(source, new Document(new Element("serialized")),
                new IdentityHashMap());
    }

    private static Document serializeHelper(Object source, Document target,
            Map table) throws Exception {
        String id = Integer.toString(table.size());
        table.put(source, id);
        Class sourceclass = source.getClass();
        Element oElt = new Element("object");
        oElt.setAttribute("class", sourceclass.getName());
        oElt.setAttribute("id", id);
        target.getRootElement().addContent(oElt);
        if (!sourceclass.isArray()) {
            Field[] fields = Mopex.getInstanceVariables(sourceclass);
            for (int i = 0; i < fields.length; i++) {
                if (!Modifier.isPublic(fields[i].getModifiers()))
                    fields[i].setAccessible(true);
                Element fElt = new Element("field");
                fElt.setAttribute("name", fields[i].getName());
                Class declClass = fields[i].getDeclaringClass();
                fElt.setAttribute("declaringclass", declClass.getName());
                Class fieldtype = fields[i].getType();
                Object child = fields[i].get(source);
                if (Modifier.isTransient(fields[i].getModifiers())) {
                    child = null;
                }
                fElt.addContent(serializeVariable(fieldtype, child, target,
                        table));
                oElt.addContent(fElt);
            }
        } else {
            Class componentType = sourceclass.getComponentType();
            int length = Array.getLength(source);
            oElt.setAttribute("length", Integer.toString(length));
            for (int i = 0; i < length; i++) {
                oElt.addContent(serializeVariable(componentType, Array.get(
                        source, i), target, table));
            }
        }
        return target;
    }

    private static Element serializeVariable(Class fieldtype, Object child,
            Document target, Map table) throws Exception {
        if (child == null) {
            return new Element("null");
        } else if (!fieldtype.isPrimitive()) {
            Element reference = new Element("reference");
            if (table.containsKey(child)) {
                reference.setText(table.get(child).toString());
            } else {
                reference.setText(Integer.toString(table.size()));
                serializeHelper(child, target, table);
            }
            return reference;
        } else {
            Element value = new Element("value");
            value.setText(child.toString());
            return value;
        }
    }
}

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
import java.lang.reflect.Field;
import java.lang.reflect.Method;
import java.lang.reflect.Modifier;
import java.util.LinkedList;
import java.util.List;

public class Mopex {
    public static Method getSupportedMethod(Class cls, String name,
            Class[] paramTypes) throws NoSuchMethodException {
        if (cls == null) {
            throw new NoSuchMethodException();
        }
        try {
            return cls.getDeclaredMethod(name, paramTypes);
        } catch (NoSuchMethodException ex) {
            return getSupportedMethod(cls.getSuperclass(), name, paramTypes);
        }
    }

    public static Field[] getInstanceVariables(Class cls) {
        List accum = new LinkedList();
        while (cls != null) {
            Field[] fields = cls.getDeclaredFields();
            for (int i = 0; i < fields.length; i++) {
                if (!Modifier.isStatic(fields[i].getModifiers())) {
                    if (!Modifier.isPublic(fields[i].getModifiers()))
                        fields[i].setAccessible(true);
                    accum.add(fields[i]);
                }
            }
            cls = cls.getSuperclass();
        }
        Field[] retvalue = new Field[accum.size()];
        return (Field[]) accum.toArray(retvalue);
    }
}

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

public class Animal {
    private String name;
    private String gender;
    private String classification;
    private int weight;
    public Animal(String name,String gender, String classification,  int weight) {
        super();
        this.classification = classification;
        this.gender = gender;
        this.name = name;
        this.weight = weight;
    }

}

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
import java.util.ArrayList;
import java.util.List;

public class Zoo {
    private String city;

    private String name;

    public Zoo(String name, String city) {

        this.city = city;
        this.name = name;
    }

    List animals = new ArrayList();

    public void add(Animal panda1) {
        animals.add(animals);
    }

}
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
import org.jdom.Document;
import org.jdom.output.XMLOutputter;

public class ZooTest {
    public static void main(String[] args) {
        Animal panda1 = new Animal("Tian Tian", "male",
                "Ailuropoda melanoleuca", 271);
        Animal panda2 = new Animal("Mei Xiang", "female",
                "Ailuropoda melanoleuca", 221);
        Zoo national = new Zoo("National Zoological Park", "Washington, D.C.");
        national.add(panda1);
        national.add(panda2);
        try {
            XMLOutputter out = new XMLOutputter();
            Document d = Driver.serializeObject(national);
            out.output(d, System.out);
        } catch (Exception ex) {
            ex.printStackTrace();
        }
    }
}

想在企業階梯中順利地一階一階往上爬？「今日管理」（Management Today）
雜誌日前指出，工作者應該注意幾個獲得升遷的秘訣：

1.願意多做一些。願意主動多做一些工作，可以贏得同事的感激，也顯示
了你已經準備好承擔更多的工作職責。

2.積極建立人際網路。無論公司內外，你認識的人越多，獲得新職務的機
會就越大。

3.執行深入細節，但是看法擴及整體。讓別人覺得你會思考公司的重要議
題，謹慎選擇適合的議題，表達你對該議題的看法。

4.熱情具有傳染性。展現出你對公司的熱情及忠誠，如果你的活力可以影
響其他人，公司會希望讓你扮演更重要的角色。

5.協助會議更順利進行。在會議中發揮助攻效果，顯示出你的獨特之處，
並且與別人建立更好的關係。

6.避免一般的事業生涯發展途徑。明天的領導人需要的經驗，可能與今天
的領導人不同，特別的事業生涯發展經歷，可以讓你在同事中鶴立雞群。


7.幾年更改一次職責。讓你保持對工作的新鮮感，也給予你更廣博的經驗
，增加競爭力。

8.有焦點，但也具彈性。決定自己想要的職務，想要的工作技能，以及你
將如何獲得它們，目標明確，但是也願意接受出現的新機會。

The class diagrams are essentially the same, but the two patterns differ in their intent.

With the State Pattern, we have a set of behaviors encapsulated in state objects; at any time the context is delegating to one of those states. Over time, the current state changes across the set of state objects to reflect the internal state of the context, so the context's behavior echanges over time as well. The client usually knows very little, if anything, about the state objects.

With Strategy, the client usually specifies the strategy object that the context is composed with. Now, while the pattern provides the flexibility to change the strategy object at runtime, often there is a strategy object that is most appropriate for a context object.

In general, think of the Strategy Pattern as a flexible alternative to subclassing; if you use inheritance to define the behavior of a class, then you're stuck with that behavior even if you need to change it. With Stategy you can change the behavior by composing with a defferent object.

Think of the State Pattern as an alternative to putting lots of conditionals in your context; by encapsulating the behaviors within state objects, you can simply change the state object in context to change its behavior.
職員為什么跳槽？是嫌錢少，還是嫌職位低？最大的原因是“我討厭這個老板！”因為不滿老板而跳槽，因為喜歡經理就投奔，看來，“攻心為上”這句名言千古不變。如果你能留住并且不斷吸引人才，就說明你是一位出色的管理者。

　　一定程度的人員流動是不可避免的，它向企業進步和招聘新的優秀人才敞開了大門，使企業能夠充滿活力。然而，過多的人員流失將不可避免地導致企業松散和成本增加。突然而來的意外人員變更將會對客戶服務和公司運營造成重創。

　　所有這些問題的關鍵在哪里？答案卻是出人意料的簡單。公平合理的補償和個人發展的機會常常是非常重要的因素，然而大多數員工離開公司卻是因為另外一個原因：令人生厭的老板。

　　員工不是離開公司，他們是離開老板

　　國外最近對20000名剛剛離開老板的員工進行了一項調查，調查發現，落后的監督管理方式是員工辭職的主要原因。員工留在公司時間的長短，很大程度上取決于他和經理的關系好壞，如果他們的關系不好，就很難得到晉升的機會。

　　來自蓋洛普的測驗顯示，75%雇員的離職是離開他們的主管而非公司。在一家跨國公司200名離職人員中，只有40人在離職時進行了薪酬談判，其中27人因公司加薪留了下來，這27人中又有25人在1年后仍然選擇了離開，他們中大多數人離開的理由就是“令人討厭的上司”。

　　美國的一項研究報告也顯示，員工當初如果以薪酬為理由向公司提出辭職，在他們離開公司3至6個月后跟蹤離職面談中，這一原因往往會讓位于其他主導原因，出現頻率最高的便是“對主管不滿”。很多人當初加盟某個單位的主要原因，是沖著該公司在社會上的知名度和在該行業里的主導地位。當分配到某個部門后，日常工作中更多的將是直接面對該部門經理，作為員工的頂頭上司，如果該部門經理不是非常優秀，或者該部門工作對公司全局沒有重要性，部門業務未見大的起色，那么部門內的員工就會士氣低落，時間一長，優秀人才必然會萌生去意，另尋其他更好的發展機會。

　　除了主管要求員工超量、超時工作、獨攬大權外，引起員工對主管不滿的還有主管任命隨心所欲，傷了員工的心；主管制造內耗，惡化團隊工作；主管不以身作則，常常以身試法；主管任人唯親，排斥異己等原因。

　　至于“主管問題”為何會被離職人員隱藏起來，一是員工自己心里不愿承認或者接受是因與主管關系不和而導致自己辭職的事實；二是提出辭職后，像放行日期、有關薪酬的結算以及今后其他企業前來進行背景調查都可能和主管有關系，自己的命運還掌握在主管手中；此外就是怕暴露出自己人際關系處理能力的薄弱，影響將來的求職等。這些都導致員工會尋找另外的原因來作為離職的理由。許多雇員流動或薪資調研報告中，人際關系在雇員流動原因中排在第五位后，導致“主管問題”沒有受到管理層的足夠重視。 

　　與其費力留人才，不如先培養優秀經理

　　公司如何才能留住員工？從更廣的范圍來說，如何才能提高生產效率和激發工人的工作熱情？

　　通過培養個人和公司的關系，使員工對公司有一種家的感覺，其中包括個人的責任具體化、遠期學習的機會和大量的非正式的、不拘束的信息反饋和交流。完成這項工作幾乎總是從同員工直接接觸的第一線的經理開始。現在是讓經理們負起責任的時候了。

　　不少人力資源專家都一致贊同這樣一個觀點：雇員真正想要的，常常是那些經理簡單就能給與的東西。

　　防止員工流失工作的公司，應該把重點放在使工作吸引人和對經理的培訓上，要把他們培養成有魄力、靈活和富于觀察的經理。讓我們看看國際知名公司的成功經驗。

　　開放式溝通交流——Container Store公司是以達拉斯為基地的一家著名零售商。它被財富雜志評為全美國最優秀的工作場所。這里的人員流動率只有20%，而大多數的零售業中的人員流動率通常在80%-120%之間。

　　第一年，該公司全職員工要接受大約235小時的培訓，并且向他們提供正式和非正式的與經理互動交流的機會。經理不但要讓員工知道做好工作的注意事項，并且還要定期接受培訓，如何為員工提供必要的援助。以經理主管領導層所稱的“直接溝通”經營管理哲學為指導原則，公司的兩千多名員工定期討論公司銷售額、公司目標和遠景計劃等，在確保開放和溝通的環境中闊步向前。

　　胡蘿卜比大棒有用——金融服務業的巨頭美國萬國寶通銀行也開始對經理進行培訓，使他們知道如何成為被公司視為作用“日漸重要”的員工們的良師益友。這些經理常常十分樂于使用內部晉升的激勵制度，激發員工的自信心和成就感，特別是在員工想另謀高就時能夠留住人心。

　　成為員工的良師益友——Autodesk Inc.是位于加利福尼亞San Rafael的一家著名電腦軟件公司。其人力資源專家和培訓專家最近設計了一項關于員工保持力的網上培訓計劃，經理們經過培訓之后將會掌握一定的技巧，運用這些技巧可以了解員工的個人事業目標，成為技能嫻熟的職業顧問。在特定時期內，他們可以根據實際情況制定一個同時適用于公司和員工的具體發展計劃，這樣的雙贏局面自然會吸引很多想在職業上有所發展的員工。

　　留不住人，就讓經理對員工流失負責

　　如何確實讓經理們對下屬員工的流動負起責任？

　　這里還有一個簡單而有效的方法，可以鼓勵和幫助經理們降低人員的流動性：把他們的福利補償和員工的流動率聯系起來。如果保持了較低的流動率，那么就對他們進行獎勵。反之，如果摩擦不斷，員工離職率很高則對他們進行處罰。這是一個很行之有效的戰術手段，但是還有待于大家的廣泛關注。

　　大多數經理都很討厭把他們的收入和其他的因素聯系起來。但是，越來越多的公司正在認識到員工的去留關鍵在于他們的經理。這種事實正在被大家廣泛的實踐，因為大多數的保留員工的計劃在實施的時候都簡單易行且成本很低。當然，使經理們接受贊同員工保留計劃和方法并不那么一帆風順。一些人說他們所做的努力對改變現在人員流動的現狀的影響力太小。另外一些人則認為這將耗費他們太多的時間。但是，如果人力資源工作人員能夠給他們開始這項工作的機會、把他們引導到正確的方向上來，并且向他們展示和說明留住優秀人才他們完全能夠做得到，完全能夠控制得了，那么經理們就會開始工作。

　　通過聯合最優秀的人才，并給他們分派有意義的工作、給他們提供發展機會和晉升的機會，經理能夠成為更出色的老板。這是一個在競爭中生存的問題。

A hook is a method that is declared in the abstract class, but only give an empty or default implementation. This gives subclasses the ability to "hook into" the algorithm at various points, if they wish; a subclass is also free to ignore the hook. 生命是一種過程。

　　事情的結果盡管重要，但是做事情的過程更加重要，因為結果好了我們會更加快樂，但過程使我們的生命充實。人的生命最后的結果一定是死亡，我們不能因此說我們的生命沒有意義。世界上很少有永恒。戀愛中的人們每天都在信誓旦旦地說我會愛你一輩子，這實際上是不真實的。最真實的說法是：“我今天，此時此刻正在真心地愛著你。” 明天也許你會失戀，失戀后我們會體驗到失戀的痛苦。這種體驗也是豐富你生命的一個過程。

　　兩點之間最短的距離并不一定是直線。

　　在人與人的關系以及做事情的過程中，我們很難直截了當就把事情做好。我們有時需要等待，有時需要合作，有時需要技巧。我們做事情會碰到很多困難和障礙，有時候我們并不一定要硬挺、硬沖，我們可以選擇有困難繞過去，有障礙繞過去，也許這樣做事情更加順利。大家想一想，我們和別人說話還得想想哪句話更好聽呢？尤其現在這個比較復雜的社會中，大家要學會想辦法諒解別人，要讓人覺得你這個人很成熟，很不錯，你才能把事情做成。

　　只有知道如何停止的人才知道如何加速。

　　我有位朋友在學滑雪的時候，最大的體會就是停不下來。他剛開始學滑雪時沒有請教練，看著別人滑雪，覺得很容易，不就是從山頂滑到山下嗎？于是他穿上滑雪板，赤溜一下就滑下去了，結果他從山頂滑到山下，實際上是滾到山下，摔了很多個跟斗。他根本就不知道怎么停止、怎么保持平衡。經過反覆練習，終于學會了在任何坡上停止、滑行、再停止。這個時候他就發現自己會滑雪了，就敢從山頂高速地往山坡下沖。因為他知道只要想停，一轉身就能停下來。只要你能停下來，你就不會撞上樹、撞上石頭、撞上人，你就不會被撞死。因此，只有知道如何停止的人，才知道如何高速前進。

　　放棄是一種智慧，缺陷是一種恩惠。

　　當你擁有六個蘋果的時候，千萬不要把它們都吃掉，因為你把六個蘋果全都吃掉，你也只吃到了六個蘋果，只吃到了一種味道，那就是蘋果的味道。如果你把六個蘋果中的五個拿出來給別人吃，盡管表面上你丟了五個蘋果，但實際上你卻得到了其他五個人的友情和好感。以后你還能得到更多，當別人有了別的水果的時候，也一定會和你分享，你會從這個人手里得到一個橘子，那個人手里得到一個梨，最后你可能就得到了六種不同的水果，六種不同的味道，六種不同的顏色，六個人的友誼。人一定要學會用你擁有的東西去換取對你來說更加重要和豐富的東西。所以說，放棄是一種智慧。做人最大的樂趣在于通過奮斗去獲得我們想要的東西，有缺點意味著我們可以進一步完美，有匱乏之處意味著我們可以進一步努力。

　　決定行動，行動產生結果。誰都能做夢想家，只有行動才能體現時間的價值。我要珍惜生命中的時光，我將立即開始行動！

楊修終于被曹操殺了，楊修覺得死得冤，死得太不值了，所以他的魂魄不愿投胎。等啊等，有一天，他見到了曹操的亡魂，急忙上前問道："明公慢走，你當初為什么要殺我？"曹操一看是楊修，便停住了腳步，笑了一下，答道："你想知道我為什么要殺你嗎？聽我慢慢道來。你的智力過人，非常聰明，你上知天文，下查地理，懂奇門，會八卦，可以說是一個奇才。但是你恰恰忘記學習一門人生的必修課，那就是領導者的心態。所以你不曉人和。今天閑著也是閑著，我給你補上這一課。

　　領導，作為一個成功人士來講，曾經遭受過多少坎坷，又遭受過多少艱辛，還遭受過多少他人的冷眼，你知道嗎？在創業階段流過多少汗，淌過多少淚，吃過多少苦，你知道嗎？成功后又承受著多大的壓力，面對著多大的困難，忍受著多大的指責，你知道嗎？他們不缺錢花，也不缺衣穿，唯獨缺少的就是他人的認可，希望的是別人來贊美他幾句，哪怕是唯心的，起碼讓他覺得他的努力沒有白費。而現實呢，沒有人這么做，他們招來的只有嫉妒的目光和無窮的排擠。這些你知道嗎？孤獨是領導者的難言之隱，他們不敢奢求其他人來贊美他，讓自己的下屬贊美一下，這個要求過分嗎？不過分！一點兒都不過分！但是你，楊修，沒有做到，相反處處和我作對。記得有一次我拿給你們一盒點心，只不過想讓你們來和我說一聲想吃，我不會不給你們吃的，興許我還會多給你們幾盒。我在盒上寫了'一合酥'，意思就是讓你們不知道其中的含義，而來向我請教，然后我會告訴你們，'合'字下面沒有'皿'，也就是說，沒有東西盛放，你們無法吃，我把盤子給你們，你們不就能吃了嗎，這樣顯得我既聰明，又和藹，有什么不好，可是你偏要把它理解為'一人一口酥'，全給我吃掉了，你說，當時我的面子往哪兒擱啊，我的心里能平衡嗎？不能！

　　記得有一次，好像是工人修一座門，問我是寬一些還是窄一些好，我身材較胖，當然想讓門寬一些，但是我要是如果這么直說，顯得我太沒有水平了，于是我靈機一動，在門上寫了一個'活'字，同'門'字合在一起就是個'闊'字。有話不明說，這是領導顯示其尊嚴的一種手段，當人們無法猜出的時候，我再給予解答，你知道嗎，這樣的感覺是多么多么的爽嗎？然而，就是因為你，楊修，我沒有爽成，反到讓你爽了一下，你毫不留情的把謎底給我揭穿了，你知道后來他們說我什么嗎，他們說：'我們的丞相怎么這么愛賣弄啊，簡單的事非要搞復雜了。'你讓我的尊嚴蕩然無存，我能不恨你嗎？

　　我要在我的兩個兒子中選出一個來繼承我的大業，曹丕和曹植都是可造之材，我有心考核一下他們的能力，這是關系到我的千秋大業的事情，結果你，楊修，偏要給曹植出謀劃策，嚴重影響了我對他們績效考核的真實性，從而誤導了我的選擇方向，你罪不容誅！曹植的落選，和你有直接的關系，你難辭其咎！你的魔爪已伸向了我的家庭，破壞了我們的父子關系，你無情的撕下了我隱私的面紗，你太可恨了！

　　大家公認我愛才，求賢若渴也是我所追求的目標。當年，彌橫是多么的囂張，當眾脫光衣服，敲著鼓罵我，我沒有生氣；徐庶之母當眾數落我的不是，還用硯臺打我，我還是沒有生氣；我待關羽如同至親，上馬金，下馬銀，三日一大宴，五日一小宴，還把赤兔馬給他，但他還是棄我而去，我仍然沒有生氣。他們這些行為，我都可以忍，唯有你，楊修，讓我忍無可忍，你比他們更可恨一千倍，一萬倍，因為你是我的下屬，是我一手把你栽培到今天，所以你最可恨。那個時候，我就已經暗下決心，要把你殺死，只是缺個機會而已。

　　我帶兵去漢中攻打劉備，久戰不勝，反而損兵折將，當時確有退意，可是我并沒有表態，而你卻自作聰明，把我的口令'雞肋'引申為'食之無味，棄之可惜'，說我要退兵，搞的軍中將士心無戰意，我被你逼的沒有選擇了。我真不明白我這個領導者在你面前，居然被你左右，你是我的領導，不，你是我的祖宗！不過這次你還不知道，你聰明到頭了，正好給了我殺你的機會，我不能錯過這個機會了，如果我錯過這次機會，今后在你面前，我永遠都是孫子。

　　我還是那句話，你的確很聰明，但正是你的小聰明，把你的性命害了，應了古訓，'聰明反被聰明誤'.你太愛耍小聰明，已達到了忘我的境界了。你眼里跟本就沒有'領導'這個概念。所有的人當中，就你敢拿領導'開涮'，就你敢挑領導的毛病，就你敢違抗領導的命令。有句俗話，你應該知道，'老虎的屁股摸不得'，你偏要摸，可想而知，你是在自尋死路！"楊修聽到這里，"撲通"一聲跪倒在地，"曹丞相，我服了，我楊修是生的窩囊，死的活該。我這輩子算是白活了，不過今天這節課補得好啊，我全明白了。時候也不早了，咱們一同去投胎吧，來世我還做您的下屬。"曹操哈哈大笑，挽著楊修的胳膊走向了奈何橋。但由于他們談話的時間太長了，比別人晚投了一千多年。

　　從此，人世間多了一對君臣：乾隆與和珅。

1. Both FM an AFM create objects. But FM do it through inheritance and AFM through object composition. 
      To create objects using FM, you need to extends a class and override a factory method. the whole point of the FM Pattern is that your're using a subclass to do your own creation for you. In that way, clients only need to know the abstract type they are using, the subclass worries about the concrete type. So,  in other words, FM keep clients decoupled from the concrete types.
      AFM provides an abstrct type for creating a family of products. Subclasses of this type define how those products are produced. To use the factory, your instantiate one and pass it into some code that is written against the abstract type. So, like FM, the clients are decoupled from the actual concrete products they use.

2. AFM group together a set of related products
3. AFM often use factory methods to implement it's concrete factories. 

4. use  AFM whenever you have families of products you need to create and you want to make sure your clients create products that belong together. use FM to decouple your client code from the concrete classes you need to instantiate, or if you don't know ahead of time all the concrete classes you are going to need , just subclass and implement the factory method.
 

1. No varible should hold a reference to a concrete class.
      If you use new, you'll be holding a reference to a concrete class. Use a factory to get around that.

2. No class should derive from a concrete class.
      If you derive from a concrete class, you're depending on a concrete class. Derive from an abstraction, like an interface or an abstraction class.

3. No method should override an implemented method of any of its base classes.
      If you override an implented method, then your base class wasn't really an abstraction to start with. Those methods implemented in the base class are meant to be shared by all your subclasses.

think of Simple Factory as a one shot deal, while with Factory Method your are creating a framework that let's the subclasses decide which implementation will be used. Simple Factory gives you a way to encapsulate object creation, but doesn't give you the flexibility of the Factory Method because there is no way to vary the products your're creating. A factory method handles object creation and encapsulates it in a subclass. This decouples the client code in the superclass from the object creation code in the subclass.
1. A factory method is abstract so the subclasses are counted on to handle object creation.
2. A factory method returns a Product that is typically used within methods defined in the superclass.
3. A factory method isolates the client from knowing what kind of concrete Product is actually created.
4. A factory method may be parameterized(or not) to select among several variations of a product.
日本索尼公司的盛田昭夫曾經說過：“日本公司的成功之道并無任何秘訣和不可言傳的公式。不是理論，不是計劃，也不是政府政策，而是人，只有人才會使企業獲得成功，因此，衡量一個主管的才能應該看他是否能得力地組織大量人員，看他或者她如何最有效地發揮每一個人的能力，并且使他們齊心協力，協調一致。作為主管，待人應該真心誠意，如果你要發揮人的作用，錢并不是最有效的工具，你應該把他們融為一家，對待他們象對待你的家人一樣。”在這里，盛田所談到的就是強調主管在日常管理事務中應該運用的領導方法和領導藝術，以更好的團結下屬，發揮團隊精神和作用。可以這樣說，在公司發展的任何階段，作為主管，都需要身先士卒，帶領下屬共同奮斗，而在這其中，主管的領導方法和領導藝術將起到很大的促進作用。

　　與員工保持親密的距離

　　現代辦公室好比一個大家庭，蘊含著其所有的和諧與不睦之處。因此，主管與員工的關系問題至關重要。作為主管，你要使員工感到既安全又獨立，既得到信任又不感壓抑，既可以提出個人問題也不怕生活受到干擾。

　　心理學家Robert Rosen（羅森）是美國華盛頓特區一家管理顧問公司的主要負責人。他說：“企業需要員工對自己的行為擔負更多的責任，以便成為企業的活躍伙伴。同時，企業必須在效率管理上擔負更多職責，這也許意味著他們不得不更加留意與員工的關系。”那么，與員工保持良好的關系恐怕不是嘴上說說就可以的，需要主管們能夠與員工保持比較親密的聯系，以使他們感到你平易近人，有什么事情可以找你幫忙。如果主管確實能夠在日常工作中注重這些，員工們會更加投入地工作。如今你投之以桃，將來他們很可能在工作上報之以李。

　　而另一些高高在上、遠離員工的主管，會使員工感到自己與其說是有血有肉的共事者，還不如說更象機械人，在這種環境中，員工的問題將不斷惡化，直到已無法補救才來一次總爆發，最終的結果只會阻礙公司的正常發展。

　　建設一個優秀的團隊

　　當今的許多主管深切感到，自己就象一個初出道的空中飛人演員。由于他們所領導的企業組織正在向團隊方向發展，所以他們必須從一個舒適、安全的平臺（即他們企業組織的傳統文化）跳到另一個平臺（即進行自我管理的團隊）。他們必須放棄一統天下的領導方式，學會授權賦能。可惜的是，這種變革并不被看作是一個振奮人心的過程，相反卻使許多主管焦慮不安。為什么？因為很多主管不知從何入手，而他們所領導的企業組織也不清楚該怎樣去幫助他們。

　　一個優秀團隊的建設剛開始時，主管們不得不花很多時間和精力來帶動你的團隊。必須明確團隊目標、員工的角色和責任。此后不久，主管需要花40%到60%的時間訓練員工去做你以前做的工作，如安排假期、分配每天的任務、生產監控等。

　　在這一成長階段，可以讓團隊成員盡可能多地承擔一些不會引致太大后果的任務。當團隊適應了新的職責后，幫助他們掃除障礙并提供各種所需資源。這一階段你需要注意以下方面：要堅持不懈，在變革過程中，幾乎所有團隊主管都經歷過至少一次的徹底失望，然后，就會出現一個突破：團隊成員或者成功地完成一項新任務，或者學會運用一項新技能，甚至會開始感謝你給予他們的幫助；注意觀察團隊的進步情況，如提前完成任務或者在某一領域展示了高度的主動性；樹立責任感，當團隊自始至終地負責一項任務時，腔岱淺Ｈ刃牡囟源庀釗撾瘛?/P>

　　在這一階段，你的團隊需要你的幫助。因此，要為他們投入一些你的個人時間，不斷為他們提供反饋，給予適當的指導。

　　團隊經過一段時間運作以后，他們能夠很好地處理人際關系問題、很好地合作，并能使業績保持在一個穩定的水平。這時，你的團隊已經不象從前一樣離不開你，因此你有更多時間謀求自己的發展。你可以在某一領域深入下去，也可以負責改進一些跨部門的工作流程，還可以想出一些能為公司或客戶增殖的好辦法。在這一階段，你的團隊可能已發展到頂峰，為避免滋生松懈或自滿情緒，需經常提醒他們團隊的目標并幫助他們認清新的任務和挑戰。繼續為他們舉辦慶祝活動，不斷激勵團隊進步，為團隊的壯大和發展提供原動力。

　　營造一個和諧寬松的環境

　　在一個公司中，營造一個和諧寬松的工作環境決定著員工的心情。而這種環境的營造，良好的物質環境當然重要，軟環境也同樣重要，而主管就是軟環境的建設者和維護者。在這樣的軟環境營造過程中，美國著名企業家瑪麗？凱的《用人之道》教給我們很多知識：

　　第一，希望別人怎樣對待自己那樣去對待別人，管理中的金科玉律就是：“你們愿意別人怎樣對待你們，你們也應該那樣去對待別人。”

　　第二，相信每個人都有專長，必須使別人感到他們自己很重要。一個主管怎樣才能使人們感到自己重要？首先是傾聽他們的意見，讓他們知道你尊重他們的想法，讓他們發表自己的見解；其次是既要人們承擔責任，又要向他們授權，不授權會毀掉人們的自尊心；最后，應該用語言和行動明確地告訴人們你贊賞他們。

　　第三，把聽意見當作頭等重要的大事來抓，掌握聽意見的藝術，聰敏的管理者是多聽少說的人。

　　第四，批評要講策略。假如某人的工作不能令人滿意，你決不可繞開這個問題，而必須表達自己的看法。不過，在提出批評時，一定要講究策略，否則就有可能出現適得其反的結果。這里應該注意的是：1、決不當眾批評人；2、要記住批評的目的是指出錯在哪里，而不是要指出錯者是誰；3、要創造出一種易于交換意見的氣氛，明確“同自己員工保持親密的關系是正常的”，因此對員工既要關心，又要嚴格，既要十分親熱，又不能損害自己的監督作用；4、無論批評什么事情，都必須找點值得表揚的事情留在批評前和批評后說。

　　第五，給別人以熱情。一個能激起熱情的平凡主張比一個不能激起熱情的非凡高見好得多，因此，主管者必須能激起部下的熱情。要實現這一目標，主管本人必須首先要有熱情。一帆風順時保持熱情并不難，但是在逆境中要保持熱情卻不太容易，這時，必須強迫自己保持熱情直到自己身上自然而然地產生出熱情，正如顧客的購買欲望會因為售貨員的冷漠態度而消失，所以主管的工作態度會影響其他人的熱情。如果一位主管對部下提出的新方案三心二意，那他十有八九得不到部下的支持，因此，缺乏熱情有可能導致毀滅性的后果。

　　第六，敞開辦公室的門。開門有兩個目的：一是使來訪者對公司有個好印象，二是為公司內部人員提供增進了解與彼此合作的機會。開門的內容，一是員工可以直接找主管交談，二是公司所有的人都彼此直呼其名，三是主管向同事表示極大的熱情，好主管應當是集體的一員。

　　第七，創造一種使部下熱愛本職工作的環境。人們越是熱愛自己的工作，干勁就會越大，也會把那項工作干得更好。因此，每個主管都應該努力創造一種使自己的部下能夠熱愛本職工作的環境。實現這個目標的一個方法是，創造一種使自己的部下感到自由和無拘無束的氣氛，因為人們在心情十分壓抑的情況下不可能干出最佳水平。另一個方法是，承認各人的志趣有差別，區別對待每一個人，分配他們去干自己有興趣的工作，精明的主管還會發現某人什么時候缺乏做某種工作所需要的愛好，他會盡力找出更適合此人干的工作。最后還有一個方法，就是主管自己對本職工作像對業余愛好一樣，以自己的工作熱情去感染部下，而不是用自己的消極情緒去影響部下。

　　成功運用每一個下屬的長處

　　人力資源管理中有一句名言，沒有“平庸的人”，只有“平庸的管理”。每個人總是有長處的，高明的主管善于從每個普通的員工身上，發現有價值的東西，并加以引導和開發。一位香港企業家認為經營管理人員有三個層次，第一個層次是商人，只做生意；第二個層次是企業家，擁有一份實業；第三個層次是組織者，是運籌帷幄的人。而組織者最主要的才能是善于把每個人安排到適當崗位上去。

　　主管的任務在于運用每個人的長處，把每個人的長處作為共同績效的建筑材料來建成組織的大廈，這幾乎是人之常識。試想一下，哪個單位的績效不是各個成員發揮各自的長處共同做出來的？因此，主管在用人的時候，要首先把著眼點放在人的長處上，弄清這個人有什么長處，如何用他的長處。唐太宗李世民曾說：“我成功的原因只有五條：……第二，一個人做事，不能樣樣都會，我用人總是用他的長處，避免用他的短處”。

　　然而，許多主管卻首先盯住了人的短處，這個不能讓他做，那個不能讓做，甚至思來想去，這個人什么也不能做，成了“廢”人。一個主管如果不能發掘人的長處并設法使長處發揮作用，那么他就只能受人的短處的影響，被短處的陰影所籠罩。從人之短處來用人，那是誤人前程，甚至可以說是“虐待”人。至于短處，那是人人都有的，主管、管理者當然也要看到人的短處，也要設法幫助克服。設法不讓短處對集體和他人發生影響，避免損害組織的績效。但必須是在發揮長處的前提下來克服短處，不能本末倒置。事實證明，人的長處得到發揮了，他也就樂于接受批評，克服短處。

　　分析下屬特點酌情對待

　　對不同類型的人美國心理學家赫茲伯格有個雙因素理論。他把人的需要分成兩種因素，工資、待遇和工作環境等叫保健因素，成長、成就等叫激勵因素。他認為不同的人追求不同，因而對這兩種因素的需要也不同。就是說，可以根據這兩種因素區分人的不同層次。他的這個理論是有一定道理的。按照他的理論，一味在事業層面上追求激勵因素的人我們稱之為主動型的人；一般追求保健因素的人我們稱他們為被動型的人。

　　—主動型的人。主動型的人一般具有較高的追求和奉獻精神，具有較為豐富的思想內涵，他們的主動意識強，往往表現出開拓精神來。對他們之間能力強的，我們應該以授權方式為主，盡量放權給他，可以交給他們復雜的、有難度的，特別是富有挑戰性、風險性和開拓性的工作。這不只是可以培養他們能力，而且會激發他們更大的創造精神。一些人甚至認為，具有高追求的人，交給他們只具有50%成功率的工作，會調動起他們最大的干勁和熱情。對他們之中能力弱的人，我們應該盡可能為他們提供學習、提高水平的條件，為他們創造好的環境，幫助他們進步，盡量交給他們有把握完成的工作，逐漸提高能力。

　　—被動型的人。這部分人比較注重物質利益、工作條件和人際環境，他們表現出來的往往是責任心，而不是進取心，思想內涵也比較簡單。對他們其中能力強的，要明確其具體責任，賦予確定的激勵機制。因成就意識較弱，所以最好是叫他做某一領域、某一方面的工作，或是技術性較強的工作。對其中能力較弱的人，一定要輔以較為完美的管理制度和激勵辦法。分配給他們較為單一、專一的工作則比較合適。

　　對個性突出、缺點、弱點明顯的能人這就是我們常說的兩頭冒尖的人。對他們，一是用長。長處顯示出來了，弱點便被克制，也容易得到克服。二是做好思想和情感溝通的工作。一年中談幾次話，肯定成績，指出問題，溝通感情。使他們感到主管的關心和理解，自己也會兢兢業業。三是放開一點，采取一忍二等的辦法。不要老是盯住人家，而是給人家留有一定的余地，幫助也只是在大事上、在關鍵性的問題上。否則，束縛住手腳就很難有所作為。

　　對有特殊才能的人一定要盡可能給他們最好的條件和待遇。他們之中有的人并不是安分者，可能有這樣那樣的問題，以致很不好管理。對此我們不只是要容忍，而且應該做好周圍人們的工作，以便使他們能夠集中精力發揮長處和優勢。在特殊的情況下，還應該放寬對他們的紀律約束和制度管理，甚至采取明面掩蓋、暗中支持的辦法。

　　對有很強能力的人采取多調幾個崗位、單位的辦法，即能夠讓他們發揮多方面的、更大的作用，又可以調動他們樂于貢獻、多出成績的積極性。對年輕又很有能力的人，則應該給幾個輕便的臺階，讓他們盡快地負起更大的責任。如果有可能，我們可以為他們創造條件，讓他們去開拓新的事業。

　　對被壓住了的能人一個是先把他們調出去，給他們顯示自己本領的機會，也給他們從另外的角度審視自己的空間。等有了成績，被公眾認可，在必要時就可以調回來加以任用。另一個辦法是把壓他們的人調開，讓能人上來。這都根據具體情況決定。

　　結束語

　　兵有兵經，但兵無常勢，弈有弈譜，但弈無定型。所以，主管們在經營過程中要懂管理學、經營學，但如何管、如何經營卻要依靠精湛的藝術去描繪。

• crust  ：外殼，面包皮；蓋以硬皮，結硬皮
• crispy :  易碎的; 精神爽快的
• dough : (名) 生面團; 錢, 現款; 似生面團的東西; 布丁
• sauce : (動) 調味, 使增加趣味 (名) 醬油, 果醬, 調味料
• toss :  (動) 拋, 投, 扔; 把...拋來拋去; 使上下搖動; 突然抬起; 搖擺, 輾轉, 顛簸 (名) 投擲, 搖擺, 拋
• diagonal : (名) 對角線, 斜列, 斜線 (形) 對角線的, 斜紋的, 斜的
• strive for : 努力, 奮斗, 苦干; 反抗, 斗爭
• lurk : (動) 潛藏, 埋伏, 潛伏; 偷偷摸摸, 鬼鬼祟祟, 潛逃; (因特網用語) 作為討論組里的被動成員 (只讀其他人的談話而不加入闡述自己的意見) (名) 潛伏; 埋伏
• dissect : (動) 解剖; 仔細分析; 切開; 細心研究
• volatile : (形) 揮發性的, 不穩定的, 可變的
• feat : (名) 壯舉, 技藝表演, 功績
• intercede : (動) 仲裁; 求情; 說項
• regression : (名) 復原, 退步, 逆行
• hypothetical :  (形) 假設的, 假定的

一流的溝通者卻像一位合氣道高手，能敏銳地測知阻力的所在，找出雙方相同的觀點，然后借勢順使，把整個溝通導向自己所要的方向。

　　在我們的話里面，有些字眼會引起別人的抗拒和爭論，我們要特別留意以避免之，這也是一流的領導者或溝通者成功之處。富蘭克林曾在他的自傳里談到他不傷和氣的溝通技巧：

　　“當我在推動任何可能引起爭論的事情時，我總是以最溫和的方式表達自己的觀點，從來不使用絕對確定或不容懷疑的字眼，而代之以下列說法：據我了解，事情是這樣子；如果我沒犯錯，我想事情該是這樣；我猜想事情是不是該這樣；就我看來，事情是不是該如此？像這樣對自己看法沒多大把握的表達習慣，多年來使我推動許多棘手的問題一帆風順。”

　　富蘭克林實在是深諳說話的重要，避免使用肯定的字眼來說服別人接受他的觀點，以免造成抗拒。在我們的生活里，有一個字頗具殺傷力，可是我們用得太習慣而渾然不覺，那個字就是“但是”。

　　如果有人說：“你說的有道理，但是……”你知道他是什么意思嗎？他是指你說的沒道理或不相關。“但是”這個字具有否定先前所說的意義。如果有人在同意你的觀點之后，再加上“但是”這兩個字，你會有什么樣的感覺呢？我相信你心里不見得會痛快的。

　　如果你把“但是”這個字替換成“也”的話，會有什么結果呢？如果你這么說：“你說的有道理，我這里也有一個滿有道理的看法……”或“那是個好主意，我這里也有一個滿好的主意……”你猜會有什么結果呢？這兩句話都是以同意對方觀點開頭，然后給自己的觀點另開一條路，未曾造成對方抗拒的心理。

　　我們要牢牢記住，在這個世界里沒有永遠抗拒的人，只有頑固且不具彈性的溝通者。就像有些話會必然地激起聽者的抗拒，然而也有些話能使聽者敞開心門，愿意與你溝通。

　　例如，如果你懂得溝通的技巧，在堅守原則的立場下，既充份表達了自己的觀點，也未激起他人的反對，請問你會有什么感覺？你是否會認為那個溝通技巧十分高明？

　　現在就讓我告訴你這套技巧，我稱其為“合一架構”。這套架構只有三句話，我希望你在與人溝通時能常常運用，使你與人和睦，充份表達己見。請記得，惟有在沒有抗拒的地方，才不會有沖突。 這里就是合一架構的那三句話：

　　“我感謝你的意見，同時也……”

　　“我尊重你的觀點，同時也……”

　　“我同意你的看法，同時也……”

　　在上面的每一句話里，你都表達了三樣事。第一，你能站在別人的立場看這件事，而不以“但是”或“不過”的字眼來否定或貶抑他的觀點，因而達成契合；第二，你正建立一個使你們攜手合作的架構；第三，你為自己的看法另開一條不會遭遇抗拒的途徑。

　　讓我舉個例子，如果有人對你說：“你百分之百的錯了。”而你反頂了一句：“我沒錯！”你認為雙方能平心靜氣的談下去嗎？我想那是不可能的，這時反倒會有沖突、有抗拒。相反地，如果你這么說：“對于這件事，我十分尊重你的看法，同時也希望你能站在我的立場聽聽我的看法。”

　　注意，在溝通時你無需贊同他的主張，但是你一定得尊重他的立場，因為畢竟各人有各人的認知方式和情緒反應。

　　你也可以尊重別人的意圖，例如，經常有人因為對某件事意見相左，繼而不尊重別人的意見，甚至聽而不聞。如果你能善用合一架構的觀念，你就會注意他的意圖而不在意他所說的，在這種理性反應下便能尋出一些新的溝通方式。

假設你與某人在核武問題上相互爭論，他主張建立核子打擊武力，而你主張凍結核子武力。雖然你們的看法是南轅北轍，但是出發的動機卻是相同，都希望確保自己和家人的安全，以及世界的和平。

　　因此對方如果這么說：“要想解決兩強的核武問題，惟一的辦法就是讓蘇聯知道美國的核子武器足以毀滅對方。”這時你可別跟他爭論，相反地你應站在他的立場說道：“我十分感謝你如此關心下一代的安全，同時我也相信除了用核武嚇阻蘇聯之外必然還有其他的方法。”

　　當你采用這個方法溝通時，對方必然覺得受到尊重，也就不會產生爭執。這套方法你可用之于任何人，不論對方怎么說，你總能找出他值得尊重、感謝、同意的觀點。你不會跟他有任何的爭執，因為你根本就不打算爭執。

　　在研討會里，我有個簡單實驗，就是讓二人一組針對同一題目相互辯論。在辯論當中，我要他們相互質問時不可在話中出現“但是”這個字眼，并且不可貶抑對方的看法。

　　這個規定有如把合氣道用在說話上，對學員們是個蠻新鮮的經驗。他們在這個實驗中學會尊重別人的看法，不以壓服對方為樂；他們能爭論但不會交惡；他們能從差異中找出共同的觀點。

　　你也可以找個人照樣練習。一番。先訂個題目，然后雙方依照前面所說的方法相互抒發己見并質問對方，像玩游戲似地去找出共同的觀點，引導對方認同自己的觀點。

　　這種溝通方式不需要你放棄自己的原則，也不需要你失去立場，但是你卻能慢慢地和對方產生契合，然后引導對方順從你的看法，更快地達成目的。

　　我們之中有許多人把討論看成是一場要決定出勝負的游戲。我們是對的，對方是錯的；我們的看法是絕對無誤的，對方卻是一派胡言。然而從合一架構的觀點上，我卻能比以前更快地達到自己的目的。

　　一流的事務員和一流的溝通者都知道，要說服一個人去做他不愿意做的事是很難的，但是要他去做他愿意做的事卻很容易。你只要能找出雙方認同的觀點，然后自然地去引導他，你就能叫他做他愿意的事。因此一個有效的溝通就得盡量避免沖突的發生，減少抗拒的可能。

　　我們的思想經常囿于舊有的思考模式，難以突破。這就有如電唱機的唱針卡在唱片上的某一條溝紋里，反覆唱著那一句歌詞。要想消除這個跳針現象，你不是在唱針頭上輕壓，使唱針越過卡住的那個部位，就是把唱針提起，再輕放到唱片的另一個部位。我們若不想讓自己也卡在舊有的思考模式上，就得換個新的方法。

　　我發現人們之所以會落入舊有模式中，乃是不知該怎么辦。有些人很可能垂頭喪氣地四處找人傾吐，期望能喚起別人的同情和關懷。這種盡全力引起別人注意的方式，就是他們改變心情的最好方法。

　　如果你有個這樣的朋友，你會怎么辦？很可能你就會如他們所期望的，坐下和他們好好地長談并安慰一番。你這樣做可能使他會覺得舒坦一些，不過也因此加強了他這一套模式，因為你的做法無異于告訴他，如果他找人傾吐，他會得到別人的關懷的。

　　請問你有沒有別的辦法呢？如果你不理睬他，甚至于當面奚落他，會怎么樣呢？這時你將發現他會楞住，無言以對，然后從這陣困惑中清醒，從此就會有新的認知方式了。

　　有時我們是需要一個好朋友，向他發抒內心的悲傷和痛苦，不過不能養成習慣，否則對你有害。你若能改變這種處事方式，你便能充份地控制自我。

　　然而有許多人告訴我們，我們無法控制自我的行為、心境和情緒，因此我們只有求助于心理醫生，可是又聽他們說這是孩提時的精神創傷或荷爾蒙分泌失常所致。難道真如他們所說的那么復雜而改不掉嗎？在這里就讓我用中止模式的方法，在瞬間改變來證明它的效果。

　　有一次班德勒說了一個親身經歷的故事，那是他到一間精神病院拜訪一位自認為是耶穌的病人。當班德勒一跟他碰面，就問他：“聽說你就是耶穌？”他說：“是的，我兒。”班德勒接口道：“我等下再來。”就把那個病人單獨扔在那里，好不困惑。

　　三四分鐘后，班德勒帶了一把卷尺，從頭到腳為那病人量了一下尺寸，就又離去。這番舉動又令那個病人困惑了一陣子。過一會兒班德勒回來，帶了一把錘子，幾根釘子和幾塊木板，并且開始釘成十字架的形狀。

　　那個自稱是耶穌的人問道：“你在做什么？”班德勒在釘下最后一根釘子后再問那位病人：“你是耶穌嗎？”那人再次回答：“是的，我兒。”班德勒就說：“那么你應該知道我來此的原因了。”

　　突然間，那人回復神智，連忙說：“我不是耶穌！我不是耶穌！”他先前的模式被班德勒一下子就終止了。

　　另外一個終止模式的例子，是數年前所舉辦的禁煙活動。那場活動建議當自己的親人想取香煙時，就送給他一個吻以取代那支香煙。這個舉動一方面打破他自動取煙的模式，另一方面可讓他懷疑舊有的取煙行為是否明智。

　　像這種終止模式的方式也可用在政界和商界，更可以用在日常生活里。經常我們會和自己周遭的人起爭執，吵到最后大家都忘了爭吵的原因，只想在這場爭執中如何“贏得勝利”，因為這是他們爭執的目的。像這樣的爭執往往會破壞雙方的友誼。

　　有時候在吵完后，你回想起來，總會覺得奇怪，為何會變成這種結果？可是在爭執的當時，你可不會想到這一層。你現在想想是否最近有過一次這樣的爭執，當時你可曾用哪一種終止爭執的方式？另外也請你為這種情況想五種終止模式的方法吧！

　　終止模式也可以做為預警信號，以便在爭執失去控制時能切斷這種爭執。我發現幽默的用語是終止爭執最佳的工具。首先你和對方得有一個約定，就是任何一方發現爭執有可能會失控時，立刻就把共同認定的那句幽默話說出來，而另一方一聽見這句話就得住口。另外由于這句幽默話能引起我們想起某件好笑的事，便能沖消一些爭執所產生的火藥味。

　　在本章里所闡述的兩個觀念，是與我們平日所知道的背道而馳的。第一，同意對方的說辭遠比制服對方的說辭更具說服力。我們今天所處的社會充滿了競爭，事事都要分出勝負。不過在溝通這件事上，如果想靠言語取勝，往往不會有任何成效。

　　相反地，你若能以同意取代反對，以引導取代制伏，你的溝通會更有成果。雖然這樣做并不容易，但是只要不斷地注意，有一天你的溝通方式會改變的。

　　第二個觀念是，我們的行為模式并非牢固地永難更改。如果我們做事的態度一直是消極的、束縛的，那并不是我們的心智出了毛病，只不過是反復使用某種不好的行為模式。

　　不管那種模式是對別人或對自己，你都得立即終止，改換成另一種新的模式。畢竟我們不是機器人，受設定的程式所擺布。對于自己的心智，我們絕對有自我控制的能力，只要有決心，認清癥結所在，改變只是瞬間之事。

　　上述兩種觀念都是從彈性的立場衍生出來。當你拼圖拼不出來，你不需重復使用一種拼法，你應該以彈性的態度換個方式試試。你的彈性越大，可選擇的機會就越多，可發展的空間就越廣，而成功便接踵而至，指日可待。
1. Observable is a class
  First, because Observable is a class, you have to subclass it. That means you can't add on the Observable to an existing class that already extends another superclass. This limits its reuse potential.
Second, because there isn't an Observable interface, you can't even create your own implementation that plays well with Java's built-in Observer API. Nor do you have the option of swapping out the java.util implementation for another.
2. Observable protects crucial methods
  If you look at the Observable API, the setChanged() method is protected. So what? Well, this means you can't call setChanged() unless you've subclassed Observable. This means you can't even create an instance of the Observable class and compose it with your own objects, you have to subclass. The design violates a second design principle here...favor composition over inheritance.
 
1. can sometimes add a lot of small classes to a design and this occasionally results in a design that's less than straightforward for others to understand.
2. got typing problems: people sometimes take a piece of client code that relies on specific types and introduce decorators without thinking through everything. Now, one great thing about this pattern is that you can usually insert decorators transparently and the client never has to know it's dealing with a decorator:
3. introducing decorators can increase the complexity of the code needed to instantiate the component.Once you've got decorators, you've got to not only instantiate the component, but also wrap it with who knows how many decorators.
1. Identify the aspects of your application thar vary and separate them from what stays the same.
2. Program to an interface, not an implementation.
3. Favor composition over inheritance.
4. Strive for loosely coupled designs between objects that interface.
5. Classes should be open for extension, but closed for modification.
6. Depend upon abstractions. Do not depend upon concrete classes.
7. Principle of  Least Knowledge - talk only to your immediate friends.
8. The Hollywood Principle - Don't call us, we'll call you.
9. A class should have only one reason to change.

A Pattern is a solution to a problem in a context.

1.The Strategy Pattern:  
defines a family of algorithms, encapsulates each one, and makes them interchangeable. Strategy lets the algorithm vary independently from clients that use it. 

2.The Observer Pattern:    
difine a one-to-many dependency between objects so that when one object changes state, all of its dependents are notified and updated automatically.

3.The Decorator Pattern : 
attaches additional responsibilities to an object dynamically.Decorators provide a flexible alternative to subclassing for extending functionality.

4.The Factory Method Pattern: 
defines an interface for creating an object, but lets subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses.

5.The Abstract Factory Patter:
provides an interface for creating families of related or dependent objects without specifying their concrete classes.

6.The Singleton Pattern:
ensures a class has only one instance, and provides a global point of access to it.

7.Command Pattern:
encapsulates a request as an object, thereby letting you parameterize other objects with different requests, queue or log requests, and support undoable operations.

8.The Adapter Pattern:
converts the interface of a class into another interface the clients expect. Adapter lets classes work together that couldn't otherwise because of incompatible interfaces.

9.The Facade Pattern:
provides a unified interface to a set of interfaces in a subsystem. Facade defines a higher-level interface that makes the subsystem easier to use.

10.The Template Method Pattern:
defines the skeleton of an algorithm in a method, deferring some steps to subclasses. Template Method lets subclasses redefine certain steps of an algorithm without changing the algorithm's structure.

11.The Iterator Pattern:
provides a way to access the elements of an aggregate object sequentially without exposing its underlying representation.

12.The Composite Pattern:
allows you to composite objects into tree structures to represent part-whole hierarchies. Composite lets clients treat individual objects and compositions of objects uniformaly.

13.The State Pattern:
allows an object to alter its behavior when its internal state changes. The object will appear to change its class.

http://www.infoxa.com/asp/book/view_lb.asp?page=41&lb=&sublb=&px=rq