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

直到最近的IE老出問題，公司派的本本裝的是win2000，用久了里面的IE經(jīng)常會彈出一個crash的對話框（似乎在XP里就很少見），然后所有打開的IE窗口都只能關(guān)閉，解決無方，于是想到了Firefox，試用一下，第一感覺是非常快，不管是load firefox還是打開新的網(wǎng)頁，基本上都是文字刷一下就出來，圖片則延遲了點，不過還是比IE做得好:) 很多小的細節(jié)都考慮得比較符合用戶的操作習(xí)慣，比如工具欄有一個下載的管理器，管理最近下載的咚咚，不用第三方軟件，而且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
另外關(guān)于Java network的一些基礎(chǔ)的教程:
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

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

---

事務(wù)的屬性

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

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

一致性：一個事務(wù)的轉(zhuǎn)換必須是把持久化的數(shù)據(jù)從一個一致的狀態(tài)轉(zhuǎn)換到另一個一致的狀態(tài)，任何發(fā)生在其間的轉(zhuǎn)換失敗，都必須保證數(shù)據(jù)能夠返回轉(zhuǎn)換之前的那個狀態(tài)。

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

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

因此，一個事務(wù)運行的最終結(jié)果只有兩個：commit ——每一步操作的成功執(zhí)行；rollback——由于執(zhí)行過程中出現(xiàn)了錯誤，rollback保證沒有一步操作執(zhí)行。

---

事務(wù)獨立性的等級

事務(wù)的獨立性用來衡量并發(fā)事務(wù)中一個事務(wù)查看另外一個事務(wù)已經(jīng)update但尚未commit的數(shù)據(jù)的能力，如果某些事務(wù)允許其他事務(wù)讀取它已經(jīng)upadte但尚未commit的數(shù)據(jù)，這些事務(wù)可能會以存在不一致的數(shù)據(jù)而roll back，或者結(jié)束不必要的等待而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. ）

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

ReadUncommitted：已經(jīng)update但尚未commit的數(shù)據(jù)可以被其他事務(wù)讀取

ReadCommitted：一個事務(wù)只有commit了的數(shù)據(jù)才可被其他事務(wù)讀取

RepeatableRead： 一個事務(wù)只有commit了的數(shù)據(jù)才可被其他事務(wù)讀取，重復(fù)的讀取則會導(dǎo)致和數(shù)據(jù)尚未提交狀態(tài)時一樣的結(jié)果

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

---

J2EE支持的事務(wù)

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

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

J2EE平臺支持了兩種類型的事務(wù)管理范式：聲明式的事務(wù)和編程式的事務(wù)（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.

軟件開發(fā)的歷史是抽象層次不斷提高的歷史，我們的工業(yè)以前是通過將電路焊接在一起以形成硬件組成的程序，這樣來進行系統(tǒng)的搭建。機器碼使得我們可以通過操作開關(guān)來輸入每條指令，數(shù)據(jù)保持在×××××。。。，后來，匯編程序通過為每種硬件平臺定義相應(yīng)助記符的形式，幫我們把這種繁瑣的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的出現(xiàn)，使得“公式翻譯”成為現(xiàn)實，COBOL和C標(biāo)準(zhǔn)使得不同硬件平臺之間的移植成為可能，后來發(fā)展出了結(jié)構(gòu)化的程序設(shè)計方式，使得編程語言更容易編寫、理解和維護。我們現(xiàn)在擁有像smalltalk、C++、Eiffel和Java，它們運用了面向?qū)ο蠹夹g(shù)，一種把數(shù)據(jù)和行為封裝到類和對象的方法。

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).

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

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.)

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

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.

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

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.

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

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.
下一階段的抽象層次在發(fā)展，如圖所示。它是基于模型的開發(fā)，在這里我們建立的是和軟件平臺無關(guān)的模型。

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.
軟件平臺無關(guān)是和硬件平臺無關(guān)類似的概念。一個硬件平臺無關(guān)的語言，如C或者Java，可以使得一個規(guī)范的編寫能夠在不同的硬件平臺上運行而不需要更改。類似地，一個軟件平臺無關(guān)的語言可以使得一個規(guī)范的編寫可以在不同的軟件平臺上運行，或者在不同的軟件架構(gòu)中運行，而不需要更改。因此，一個軟件平臺無關(guān)的規(guī)范可以映射到多處理器/多任務(wù)CORBA環(huán)境，或者一個C-S關(guān)系數(shù)據(jù)庫環(huán)境，而不需要更改模型。

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.
總的而言，由概念模型所驅(qū)動的數(shù)據(jù)的組成和處理也許和實際的數(shù)據(jù)組成和處理不完全相同。如果我們考慮兩個概念，比如“customer”和“Account”，將他們建模程UML的類圖以期望能夠被用。

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

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對模式的定義是：模式，簡單而言，是出現(xiàn)在世界上的一個事物以及對應(yīng)的規(guī)則，這種規(guī)則告訴我們?nèi)绾稳ソ⒃撌挛铮裁磿r候應(yīng)該建立該事物。它是一個過程，也是一件事物，是對一個事物的描述以及對一個產(chǎn)生該事物的過程的描述。就是說，模式是一種規(guī)則之余，它還是一種現(xiàn)象、現(xiàn)狀和事物。

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

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

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

Structure?結(jié)構(gòu)

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

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


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

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

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

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

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

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

Operation中文譯作操作，是指類所定義的行為的聲明部分，一般是名稱、參數(shù)和返回類型。通常也叫對象的接口（Interface），該信息用于告訴對象需要它做什么。
Method譯為方法，是指上訴操作的實施，即當(dāng)調(diào)用接口時被執(zhí)行的代碼。
兩者的區(qū)別，簡單地來說，一個是聲明，一個是實現(xiàn)。不澄清的話很容易混淆。