一直有留意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》。不过得答辩之后才有时间了。