加载中...

本来我尽量避免关于方法论方面的主义之争，但一些话如骨鲠在喉，不吐不快。
软件领域方法论大师的著作发人深省，通常代表着软件开发的未来模式。当然，我们在读大师之后，掩卷沉思之余，最好也保持自己的独立意见。
希望本文能够唤起一些对基本概念和基本功的重视（追逐新潮概念之余，同时也固本培源）。

1. Domain Object的重新提出的背景

Domain Object并不是一个全新的概念，而是继承以前的纯面向对象开发的思路。
由于当前O/R Mapping, DAO开发结构的层次划分，导致出现了大量的纯粹数据对象。这些数据对象只带有getter, setter属性，而不具有属于自己的方法，起着Data Transfer Object的作用。
Domain Object 则是重新提出并进一步探讨纯面向对象编程的概念：对象不仅应该具有数据，而且应该具有自己的方法。

这个过程和Spring的出现过程很像。
EJB时代之前，大家本来就是采用着轻量编程模型，只是那个时候，轻量编程架构还不成体系。EJB时代中，还坚持轻量编程模型，难免被看作顽固保守。EJB时代之末，轻量编程架构Spring大获成功。

2. Domain Object的划分准则

Domain Object是纯粹的OO对象(这

目前整个开发社区对AOP(Aspect Oriented Programing)推崇备至，也涌现出大量支持AOP的优秀Framework，--Spring， JAC， Jboss AOP 等等。AOP似乎一时之间成了潮流。Java初学者不禁要发出感慨，OOP还没有学通呢，又来AOP。本系列文章便是为您做出这方面的补救，只是通过一个简单的例子便可以向初学者展示一下如何来进行AOP。

为了简单起见，例子没有没有使用任何第三方的AOP Framework，而是利用Java语言本身自带的动态代理功能来实现AOP。

让我们先回到AOP本身，AOP主要应用于日志记录，性能统计，安全控制，事务处理等方面。它的主要意图就要将日志记录，性能统计，安全控制等等代码从商业逻辑代码中清楚的划分出来，我们可以把这些行为一个一个单独看作系统所要解决的问题，就是所谓的面向问题的编程(不知将AOP译作面向问题的编程是否欠妥)。通过对这些行为的分离，我们希望可以将它们独立地配置到商业方法中，而要改变这些行为也不需要影响到商业方法代码。

AOP是面向方面（

静态字段
•        避免使用非final的公共静态变量
应尽可能地避免使用非final公共静态变量，因为无法判断代码有无权限改变这些变量值。
•        一般地，应谨慎使用易变的静态状态，因为这可能导致设想中相互独立的子系统之间发生不可预知的交互。

缩小作用域
作为一个惯例，尽可能缩小方法和字段的作用域。检查包访问权限的成员能否改成私有的，保护类型的成员可否改成包访问权限的或者私有的，等等。

公共方法/字段
避免使用公共变量，而是使用访问器方法访问这些变量。用这种方式，如果需要，可能增加集中安全控制。
对于任何公共方法，如果它们能够访问或修改任何敏感内部状态，务必使它们包含安全控制。
参考如下代码段，该代码段中不可信任代码可能设置TimeZone的值：

 private static TimeZone  defaultZone = null;

 

       public static synchronized void setDefault(TimeZone zone)

亲爱的朋友：

    欢迎您在新浪博客安家，您的博客地址是：http://blog.sina.com.cn/chargecard

    您可以用文字、图片、视频记录和展示最真实的自我，与网友交流，与线上好友聊天，还能通过手机发表博文和上传图片，随时随地记录心情和身边趣闻。

    我们为您提供了丰富的炫酷模板来装点您在网上的家园，强大的音乐播放功能更能陪伴您的网络生活。准备好了吗？现在就开始精彩的博客之旅！