一直有留意Firefox對IE的沖擊，不過以前用IE也并沒覺得有什么大問題，就一直用下來。

直到最近的IE老出問題，公司派的本本裝的是win2000，用久了里面的IE經常會彈出一個crash的對話框（似乎在XP里就很少見），然后所有打開的IE窗口都只能關閉，解決無方，于是想到了Firefox，試用一下，第一感覺是非常快，不管是load firefox還是打開新的網頁，基本上都是文字刷一下就出來，圖片則延遲了點，不過還是比IE做得好:) 很多小的細節都考慮得比較符合用戶的操作習慣，比如工具欄有一個下載的管理器，管理最近下載的咚咚，不用第三方軟件，而且Firefox比IE小巧多了（4.8M），Simple is beautiful，呵呵，I like it.

If Java uses the pass-by reference, why won't a swap function work?

Your question demonstrates a common error made by Java language newcomers. Indeed, even seasoned veterans find it difficult to keep the terms straight.

Java does manipulate objects by reference, and all object variables are references. However, Java doesn't pass method arguments by reference; it passes them by value.

Take the badSwap() method for example:


public void badSwap(int var1, int var2)
{
??int temp = var1;
??var1 = var2;
??var2 = temp;
}


When badSwap() returns, the variables passed as arguments will still hold their original values. The method will also fail if we change the arguments type from int to Object, since Java passes object references by value as well.

Now, here is where it gets tricky:


public void tricky(Point arg1, Point arg2)
{
??arg1.x = 100;
??arg1.y = 100;

??Point temp = arg1;
??arg1 = arg2;
??arg2 = temp;
}

public static void main(String [] args)
{
??Point pnt1 = new Point(0,0);
??Point pnt2 = new Point(0,0);
??System.out.println("X: " + pnt1.x + " Y: " +pnt1.y);
??System.out.println("X: " + pnt2.x + " Y: " +pnt2.y);
??System.out.println(" ");
??tricky(pnt1,pnt2);
??System.out.println("X: " + pnt1.x + " Y:" + pnt1.y);
??System.out.println("X: " + pnt2.x + " Y: " +pnt2.y);??
}


If we execute this main() method, we see the following output:


X: 0 Y: 0
X: 0 Y: 0

X: 100 Y: 100
X: 0 Y: 0



The method successfully alters the value of pnt1, even though it is passed by value; however, a swap of pnt1 and pnt2 fails! This is the major source of confusion. In the main() method, pnt1 and pnt2 are nothing more than object references. When you pass pnt1 and pnt2 to the tricky() method, Java passes the references by value just like any other parameter. This means the references passed to the method are actually copies of the original references. Figure 1 below shows two references pointing to the same object after Java passes an object to a method.

Figure 1. After being passed to a method, an object will have at least two references

Java copies and passes the reference by value, not the object. Thus, method manipulation will alter the objects, since the references point to the original objects. But since the references are copies, swaps will fail. As Figure 2 illustrates, the method references swap, but not the original references. Unfortunately, after a method call, you are left with only the unswapped original references. For a swap to succeed outside of the method call, we need to swap the original references, not the copies.

Figure 2. Only the method references are swapped, not the original ones

O'Reilly's Java in a Nutshell by David Flanagan (see Resources) puts it best: "Java manipulates objects 'by reference,' but it passes object references to methods 'by value.'" As a result, you cannot write a standard swap method to swap objects.

Resources

• Practical Java Programming Language Guide Peter Haggar (Addison-Wesley 2000):
  http://www1.fatbrain.com/asp/bookinfo/bookinfo.asp?theisbn=0201616467
  
• Java in a Nutshell David Flanagan (O'Reilly and Associates 1999):
  http://www1.fatbrain.com/asp/bookinfo/bookinfo.asp?theisbn=1565924878

http://www.physics.orst.edu/~rubin/nacphy/brian/socket.html
另外關于Java network的一些基礎的教程:
http://java.sun.com/docs/books/tutorial/networking/index.html

http://www-128.ibm.com/developerworks/cn/java/j-jtp05273/
不過翻譯得比較爛，還是看英文吧：
http://www-128.ibm.com/developerworks/library/j-jtp05273.html

?很老的文章，不過關于事務的闡述還是比較全面的。全文可見：http://www.javaworld.com/jw-07-2000/jw-0714-transaction.html
一個事務可以定義為由一組操作組成的不可分割的單元，它們要么全部被執行，要么全部不執行以保持事數據完整性。比如，從你的支票帳戶到你的儲蓄賬戶進行100美元的轉帳包含以下兩步操作：從支票賬戶登記借出100美元，然后在儲蓄賬戶添加100美元。這兩步必須同時被執行或者不執行以保護數據的完整性和一致性，以及銀行和客戶之間的利息核算。因此，這兩步的操作組成了一個事務。

---

事務的屬性

所有的事務都具備以下幾個屬性：原子性、一致性、獨立性以及持久性（縮寫為ACID）。

原子性：意味著不可分割，一組操作是不可分割的，我們稱之為原子的。

一致性：一個事務的轉換必須是把持久化的數據從一個一致的狀態轉換到另一個一致的狀態，任何發生在其間的轉換失敗，都必須保證數據能夠返回轉換之前的那個狀態。

獨立性:? 事務之間應互不影響，也就是說，一個處于未完成狀態的事務（未commit或rollback），必須獨立于其他的事務；即使幾個事務同時運行，對其中每一個事務來講，其他的事務也必須在它之前或者之后完成，所有的并發事務都必須按照實際的順序依次完成。

持久性：一旦一個事務成功地提交完成之后（commit），由該事務所帶來的狀態的改變必須是穩定和持久的，即使在提交完成之后發生了其他的錯誤也不受影響。

因此，一個事務運行的最終結果只有兩個：commit ——每一步操作的成功執行；rollback——由于執行過程中出現了錯誤，rollback保證沒有一步操作執行。

---

事務獨立性的等級

事務的獨立性用來衡量并發事務中一個事務查看另外一個事務已經update但尚未commit的數據的能力，如果某些事務允許其他事務讀取它已經upadte但尚未commit的數據，這些事務可能會以存在不一致的數據而roll back，或者結束不必要的等待而commit成功。（ those transactions could end up with inconsistent data were the transaction to roll back, or end up waiting unnecessarily were the transaction to commit successfully. ）

越高等級的獨立性意味著越少的并發性，并且越有可能成為系統性能的瓶頸，但它也減少了讀取到不一致數據的機會。一個好的應用原則是在可接受的系統性能基礎上選擇盡可能高的獨立性。以下是通常的獨立性等級劃分，從最低到最高如下：

ReadUncommitted：已經update但尚未commit的數據可以被其他事務讀取

ReadCommitted：一個事務只有commit了的數據才可被其他事務讀取

RepeatableRead： 一個事務只有commit了的數據才可被其他事務讀取，重復的讀取則會導致和數據尚未提交狀態時一樣的結果

Serializable： 這是最高等級的獨立性等級，保證了一個事務對數據排他性的讀寫訪問，它包含了ReadCommitted和RepeatableRead級別的所有限制，同時保證所有的事務必須逐個執行，以獲取最大程度的數據完整性，這導致了最低的運行性能以及最少的并發性，注意，這里的Serializable和Java里面的java.io.Serializable毫無聯系。

---

J2EE支持的事務

J2EE平臺包括了規范、兼容性test suite，application開發藍圖，以及參考實現。基于相同的規范，眾多的開發商提供了不同的應用服務器和實現。J2EE組件的設計是基于規范而非基于特定的產品（比如基于某個特定的應用服務器）。J2EE應用程序里的組件利用了J2EE容器和服務器所提供的基礎服務，因此只需要將關注點放在處理業務邏輯上，J2EE通過部署描述符，使用聲明式的屬性，支持可伸縮的部署以及在目標環境中可定制的能力。J2EE的目標是保護IT投資以及降低application開發的成本，J2EE的組件可以自己開發也可從外面的代理商處獲得，這樣可以使得你的IT部門的成本降低并提高了可伸縮性。

J2EE所提供的基礎服務中一個重要部分便是對事務的支持，在J2EE規范中，描述了Java事務的API（JTA，Java Transaction API），JTA主要包括了幾個接口：javax.transaction.UserTransaction和javax.transaction.TransactionManager。UserTransaction接口提供給application組件，對application組件而言，底下的J2EE服務器和TransactionManager之間的交互是透明的。TransactionManager的實現提供給應用服務器對事務邊界的控制。J2EE的application組件提供了對JTA的UserTransaction和JDBC的事務的支持。

J2EE平臺支持了兩種類型的事務管理范式：聲明式的事務和編程式的事務（declarative transaction demarcation and programmatic transaction demarcation. ）

...(to be continued)

The history of software development is a history of raising the level of abstraction. Our industry used to build systems by soldering wires together to form hard-wired programs. Machine code let us store programs by manipulating switches to enter each instruction. Data was stored on drums whose rotation time had to be taken into account so that the head would be able to read the next instruction at exactly the right time. Later, assemblers took on the tedious task of generating sequences of ones and zeroes from a set of mnemonics designed for each hardware platform.

軟件開發的歷史是抽象層次不斷提高的歷史，我們的工業以前是通過將電路焊接在一起以形成硬件組成的程序，這樣來進行系統的搭建。機器碼使得我們可以通過操作開關來輸入每條指令，數據保持在×××××。。。，后來，匯編程序通過為每種硬件平臺定義相應助記符的形式，幫我們把這種繁瑣的0/1操作中解放出來。

At some point, programming languages, such as FORTRAN, were born and "formula translation" became a reality. Standards for COBOL and C enabled portability among hardware platforms, and the profession developed techniques for structuring programs so that they were easier to write, understand, and maintain. We now have languages like Smalltalk, C++, Eiffel, and Java, each with the notion of object-orientation, an approach for structuring data and behavior together into classes and objects.
到了后來，編程語言諸如FORTRAN的出現，使得“公式翻譯”成為現實，COBOL和C標準使得不同硬件平臺之間的移植成為可能，后來發展出了結構化的程序設計方式，使得編程語言更容易編寫、理解和維護。我們現在擁有像smalltalk、C++、Eiffel和Java，它們運用了面向對象技術，一種把數據和行為封裝到類和對象的方法。

As we moved from one language to another, generally we increased the level of abstraction at which the developer operates, which required the developer to learn a new, higher-level language that could then be mapped into lower-level ones, from C++ to C to assembly code to machine code and the hardware. At first, each higher layer of abstraction was introduced only as a concept. The first assembly languages were no doubt invented without the benefit of an (automated) assembler to turn mnemonics into bits, and developers were grouping functions together with the data they encapsulated long before there was any automatic enforcement of the concept. Similarly, the concepts of structured programming were taught before there were structured programming languages in widespread industrial use (for instance, Pascal).

當我們從一種語言發展到另一種語言的時候，通常我們提高了開發者進行開發所處的抽象層次，這需要開發者學習新的、更高層次的能夠映射到低層次的語言，如C++到C到匯編代碼到機器碼和硬件。最初，每一個更高層次的抽象只是作為一個概念被引入。最初的匯編語言被發明的時候，作為把助記符轉換到字節碼的匯編器并沒有體系出什么明顯的又是。。。。，類似的，結構化程序設計的概念也顯得很不為人接受直到結構化編程語言在工業界廣為使用。

Over time, however, the new layers of abstraction became formalized, and tools such as assemblers, preprocessors, and compilers were constructed to support the concepts. This had the effect of hiding the details of the lower layers so that only a few experts (compiler writers, for example) needed to concern themselves with the details of how those layers work. In turn, this raises concerns about the loss of control induced by, for example, eliminating the GOTO statement or writing in a high-level language at a distance from the "real machine." Indeed, sometimes the next level of abstraction has been too big a reach for the profession as a whole, only of interest to academics and purists, and the concepts did not take a large enough mindshare to survive. (ALGOL-68 springs to mind. So does Eiffel, but it has too many living supporters to be a safe choice of example.)

隨著時間的過去，然而，新的抽象層次也開始正式形成，相應的工具如匯編器、預處理器和編譯器開始出現以支持這些概念。它們把低抽象層次的細節隱藏，使得只有少數的專家（如編譯器的編寫者）需要關心這些細節如何工作。。。。。

As the profession has raised the level of abstraction at which developers work, we have developed tools to map from one layer to the next automatically. Developers now write in a high-level language that can be mapped to a lower-level language automatically, instead of writing in the lower-level language that can be mapped to assembly language, just as our predecessors wrote in assembly language and had that translated automatically into machine language.

隨著開發者開發的抽象層次的提高，我們開發出從一個層次自動映射到另一個層次的工具。開發者現在只需編寫高層次的編程語言，之后的轉換將是自動進行的。

Clearly, this forms a pattern: We formalize our knowledge of an application in as high a level a language as we can. Over time, we learn how to use this language and apply a set of conventions for its use. These conventions become formalized and a higher-level language is born that is mapped automatically into the lower-level language. In turn, this next-higher-level language is perceived as low level, and we develop a set of conventions for its use. These newer conventions are then formalized and mapped into the next level down, and so forth.

顯然，這形成了一種模式：我們不斷地提高抽象的層次的概念，隨著時間的過去，我們學會了如何使用這種語言以及應用一系列的使用約束。這些約束變成正式后一種新的語言誕生了，而這種下一代的語言是從低層次被感知的，當我們定義一系列的使用約束之后，這些新的約束又被正式化，來推動下一階段的發展。不斷地循環。

The next level of abstraction is the move, shown in Figure 1-1, to model-based development, in which we build software-platform-independent models.
下一階段的抽象層次在發展，如圖所示。它是基于模型的開發，在這里我們建立的是和軟件平臺無關的模型。

Figure 1-1. Raising the level of abstraction

Software-platform independence is analogous to hardware-platform independence. A hardware-platform-independent language, such as C or Java, enables the writing of a specification that can execute on a variety of hardware platforms with no change. Similarly, a software-platform-independent language enables the writing of a specification that can execute on a variety of software platforms, or software architecture designs, with no change. So, a software-platform-independent specification could be mapped to a multiprocessor/multitasking CORBA environment, or a client-server relational database environment, with no change to the model.
軟件平臺無關是和硬件平臺無關類似的概念。一個硬件平臺無關的語言，如C或者Java，可以使得一個規范的編寫能夠在不同的硬件平臺上運行而不需要更改。類似地，一個軟件平臺無關的語言可以使得一個規范的編寫可以在不同的軟件平臺上運行，或者在不同的軟件架構中運行，而不需要更改。因此，一個軟件平臺無關的規范可以映射到多處理器/多任務CORBA環境，或者一個C-S關系數據庫環境，而不需要更改模型。

In general, the organization of the data and processing implied by a conceptual model may not be the same as the organization of the data and processing in implementation. If we consider two concepts, those of "customer" and "account," modeling them as classes using the UML suggests that the software solution should be expressed in terms of software classes named Customer and Account. However, there are many possible software designs that can meet these requirements, many of which are not even object-oriented. Between concept and implementation, an attribute may become a reference; a class may be divided into sets of object instances according to some sorting criteria; classes may be merged or split; statecharts may be flattened, merged, or separated; and so on. A modeling language that enables such mappings is software-platform independent.
總的而言，由概念模型所驅動的數據的組成和處理也許和實際的數據組成和處理不完全相同。如果我們考慮兩個概念，比如“customer”和“Account”，將他們建模程UML的類圖以期望能夠被用。

一直不是很理解單點選擇，今天找到了一點關于它的資料：

The Single Choice principle:
?whenever a software system must support a set of variants, clients using objects from this set should not have knowledge of all the elements in the set. A violation of this principle can be illustrated with the variants of Pascal or the unions of C (as long as the union is placed inside a struct and there is a field that acts as a type descriptor). Code written that acts upon one of these “multiple personality entities”, must be queried for its actual type, and we must program accordingly. This will produce multiple selection constructs in any module that uses these variant types.

Such constructs will become a hindrance to software change and evolution. Any addition of a new type to the variant set will force modifications in all modules that have to query the type to act accordingly. This multiple choices spread around many modules of a system is exactly the opposite to the single choice principle.

?

Traditional languages and paradigms do not provide a solution. On the other hand, object orientation, via polymorphism and dynamic binding present an elegant and complete implementation of this principle.

This concludes our consideration of the properties necessary for good modular structures. It will be seen that Abstract Data Types provide an adequate specification for modules that are consistent with the properties developed in this section. Eventually, we will cross the bridge into the software world and introduce the class as a potentially partial implementation of an Abstract Data Type.

著名建筑大師Alexander對模式的定義是：模式，簡單而言，是出現在世界上的一個事物以及對應的規則，這種規則告訴我們如何去建立該事物，什么時候應該建立該事物。它是一個過程，也是一件事物，是對一個事物的描述以及對一個產生該事物的過程的描述。就是說，模式是一種規則之余，它還是一種現象、現狀和事物。

第二章 an Introduction to Patterns
一開始通過一個例子引入Observer Pattern，在這本書中，對模式的描述是用以下格式來進行的：

Observer
?Intent?意圖
??????在對象間定義一個一對多的依賴（dependency）關系，把這些物體分為兩種角色，一種是被觀察者（一），一種是觀察者（多），當被觀察者狀態發生改變的時候，所有依賴于它的觀察者都將得到通知

Varies?變化
??????變化的地方在于，觀察者的數目是隨時可以更新的，并且要保證觀察者們總能得到更新（stay?up-to-date）

Structure?結構

Comments?評論
??????觀察者模式也被稱為“發布者－訂閱者”模式，它的一個主要用途是在document-view結構中（注：在MVC中，主要的兩個模式分別是觀察者模式和Mediator模式），文章認為，觀察者模式的復雜性在于，在實現上選擇Push模型還是Pull模型是一個比較難以抉擇的問題。（注：Push和Pull并不是針對通知而言，兩種模型中都是被觀察者通知觀察者，而非Pull中觀察者去輪詢被觀察者，兩者的區別是，Push模型是指由被觀察者向觀察者發送狀態更改通知的同時發送觀察者相應通知所需的一切被觀察者內部的信息，而Pull模型則是被觀察者只簡單地告訴觀察者狀態發生了改變，觀察者需要再次向被觀察者查詢才可以做下一步的響應動作，兩者所使用的場合是不一樣的，具體而言，Push模型用在它確定觀察者一定會作出響應，因此被觀察者只需一次到位發送全部消息，而Pull模型則考慮到觀察者眾多，未必每一個都需要相同的信息，另外也不是每一個都需要對通知作出響應）

在第三章，介紹了OO相關技術包括UML，其中提到了一個概念：在一個繼承體系中，良好的做法是越往上放越多的Code，而Data則放到越下層（子類or實現類）越好。文章是這樣解釋的：將公共代碼盡可能地放到繼承層次的上方這樣它可以被重用（和數據不同，在繼承的過程中，當子類實例不需要使用的時候，代碼也不會有額外的cost），而數據元素則應該放到越低越好，這樣你不會為不需使用的數據成員付出代價。如下圖：


第四章講的是一個電腦公司的銷售系統，對配件的零售和各種搭配銷售，要求系統能夠統一對待，這里引入了Composite模式，這里不詳述，因為還是比較簡單的。

第五章講的是Decorator模式，首先引入了一個漢堡店的系統，介紹了組合爆炸的設計，并引入Decorator，解決了這種問題。

第六章講的是不同編程語言對模式的實現問題，設計模式和習慣用法（idiom）比較起來，后者是與特定語言相關的，而設計模式則是與語言無關的，這指的是支持OO的語言都支持設計模式，只不過實現起來的復雜程度各有不同，文章舉了一個例子用VB來實現State模式，再用Java來實現，得出上述結論。

第七章第八章我就沒詳細看了，一是覺得這里的圖用的不是標準UML圖，看起來不太順眼，另一個則是內容似乎沒什么特別的。書的最后三分之一都是附錄：代碼。

總的而言，這本書不算一本經典的書，由于在圖書館借的，在還書之前翻了一下。下次打算看的模式書是《Head First Design Pattern》。不過得答辯之后才有時間了。

論文真煩人啊，希望可以順利通過了。