[摘要]

类的初始化和对象初始化是 JVM 管理的类型生命周期中非常重要的两个环节，Google 了一遍网络，有关类装载机制的文章倒是不少，然而类初始化和对象初始化的文章并不多，特别是从字节码和 JVM 层次来分析的文章更是鲜有所见。

本文主要对类和对象初始化全过程进行分析，通过一个实际问题引入，将源代码转换成 JVM 字节码后，对 JVM 执行过程的关键点进行全面解析，并在文中穿插入了相关 JVM 规范和 JVM 的部分内部理论知识，以理论与实际结合的方式介绍对象初始化和类初始化之间的协作以及可能存在的冲突问题。


本文发表于IBM DW,详细正文请见 解析JAVA类和对象的初始化过程
网址:http://www-128.ibm.com/developerworks/cn/java/j-lo-clobj-init/index.html

Headius

然后再是对系统分层，分包，几乎没有多少中间接口，相临层之间总是紧耦合的调用，造成了层与层的改动牵连边过大。
 
写出来的框架就像工具包一样，由一大堆看起来没有联系的类堆积而成。

后来，经历过一次大项目后，开始关注一些建模理论以及开源框架，对先前的框架设计思想产生极大的冲击，开始关注系统的整体搭配，接口解耦，代码重用，自动化控制程度有所提高。
但感觉问题还是依然很严峻，主要表现在：对系统的把握层次仍然偏低(从代码角度出发)，缺乏对系统整体的抽象能力和建模能力。对零散的业务规则难以抽象出很好的业务模型并以与系统架构结合起来。

总的来说我经历了两个阶段：1。以公用基础件为核心的积木式开发 2。以局部框架结构(实现)为起点，分层整合的泛射式开发(最明显的问题就是层层之间不成一体，项目越大越到后期就越松散变得越来越难以控制)

目前，开始将目光从系统业务层面出发，以架构为主，逐步向框架结构设计过渡的方向发展，但这时常令我感到力不从心，毕境理论归理论，现实中还需要丰富的实践经验去累积。

首先引用说明一下Domain Model 的定义：

Domain Model ： An object model of the domain that incorporates both behavior and data.

Domain Model 分两种：

1  Simple Domain Model (Active Record)

它的特点是POJO和TABLE STRUCTURE一一对应，建模基于数据库设计。Hibernate走的就是这个路子，说它贫血，意思就是指它只有data，没有behavior。(但我们实际可以通过HBM文件的定义和映射，在PO中适当的加入一些基本的业务逻辑的。)

在这种模式下，POJO自己的CRUD操作都应该放在自己的类里面。其他复杂的业务逻辑会放到外面的Service layer。

2  Rich Domain Model (Data Mapper)

它的特点是POJO和TABLE STRUCTURE并不一一对应，建模天马行空，完全取决于业务逻辑。domain object和table之间的mapping，由Data Mapper完成，domain object不用管数据表是何等结构，甚至不用管Data Mapper怎么操作。

1.识别某种业务行为的一个很确定的原则：

       domain logic只应该和这一个domain object的实例状态(并非“持久”状态)有关，而不应该和一批domain object的状态有关.

进一步的说：主要看logic是否只和这个object(注：指自身)的状态有关，如果只和这个object(注：指自身)有关，就是domain logic；如果logic是和一批domain object(注：指同类型的实体)的状态有关，就不是domain logic，而是business logic。

2.Domain Model 与 Hibernate PO 的区别：

领域模型的代码实现需要用一组互相协作的类来完成，每一个或者一组类承担这个领域模型的某个特征。而Hibernate的实体类只不过是其中的一组类，它承担的职责就是保持领域模型的状态的。

3.基于Domain Model 分析与设计的方法规则：

应该由领域模型来驱动你的软件内在规则，由需求驱动你的软件外在交互.

最后，我想补充的是：根据目前的O/R Mapping技术，我们在实际项目开发中，能真正做到 富领域模型 还不现实(因为我们还要考虑诸如性能、目前O/R持久化特性等等问题)，更何况，我们的MODEL DATA最终需要被持久化，因此，我比较反对在DOMAIN MODEL 中直接通过任何方式做任何持久化操作，因为这会让你所设计的MODEL无法独立化，难以单元测试，并且与加入了一些外界无关的东西，这不符合对象的本质(对象本身是不能持久化的)。虽然我们做不到完整意义上的Domain Driving Model Development，但我们可以在项目实际开发中因为性能、结构简化等等上面得到补偿，这已经值得欣慰了。