"轻快的JAVA"-读书笔记

        最近在读<轻快的JAVA>,----BETTER,FASTER,LIGHTER JAVA---.光听名字就够诱惑的了, 看了之后更是产生强烈共鸣,面对大量的 "企业级" 应用框架和铺天盖地的解决方案,以及根圣经一样厚的设计模式,我这个java初学者有点头晕了. 看了本书之后,觉得自己以前貌似走了一些弯路,一味地追求技术,反而忽略了JAVA语言本身,下面是一些读书笔记, 写下来时刻提醒自己!

       第三章中提到一个观点---"将框架分层",作者说道:

       "分层的基础只有几种不同的类型:

                                           

•  抽象层:抽象层为它的用户展现了较为简单的接口.外观层也是个抽象层
• 应用层:执行应用程序指定的工作
• 服务层:类似与应用层,但他们提供了供许多应用程序使用的共有服务.服务层与应用层之间的界限是很模糊 的

如果专注于构建良好的接口,会让你的层次更有效率.对于优良接口,还是有些基本原则的:

• 完整的:应该能够通过接口来使用层次的每个功能
• 紧密的:别让接口出现不必要的重复,当你有重复时,出错的几率更高.
• 方便的
• 坚固的:接口应该能够防止误用.如果一个null值会破坏你的代码,应该要抛出恰当的异常
• 一致性和可预测性:接口应该标准化,并且以相同的方式执行类似的工作
• 包装精良的:通常,几个小的,较专注的接口将比一个大包的接口要好     

Java应用程序应该有哪些层?

• 业务领域模型层:服务与接口的构建都是围绕该层来对模型进行持久化,显示,通知与操作
• 数据访问:
• 通信;(webservice xml等)
• 外观层:是业务模型的主要客户.目标是要提供高级的接口.在加入外观层之前,必须要了解他提供的价值.
• 用户接口 : (MVC)        

重构以降低耦合:要消除微耦合和巨耦合,下面是他们的一些表现形式

微耦合:

       1. 直接访问:        当你直接调用其他类上的方法或访问他的成员变量时,你就是把他们耦合在了一起.解耦通常的做法是插入某种类型的媒介 . 要记得接口对解耦是无用的,除非他们是成对出现factory的.下面的代码:

                       MyInterface myinterface = new MyObject();

不会比下面这行好到那里去:

                     MyObject myinterface = new MyObject();

只有下面这样才能完全解耦:

                   MyInterface myinterface = MyFactory.getObject();

2.继承:

          要分清什么时候使用 implementation , 什么时候使用 interface

3.可传递的耦合:

        若A与B耦合,B与C耦合,则A与C耦合.这种耦合通常是无害的,但很可能导致失控.你在处理嵌套时会特别痛苦,如:

          store.getAddress().getCountry().getState().getCity()

巨耦合

1.通信模型:

2.外观层:外观层并没有降低耦合,而是将耦合转移到较不固定的地方,不过,外观模式还是有诸多优点的.

3.共享数据:不管是使用缓冲区还是参数列表,问题是一样的,下面策略可以减少共享数据的两个子系统间的耦合:

   容许选择性的参数

   使用KEY-VALUE对

4.数据库:(嘿嘿,这个有很多优秀的框架支持,就不说了....)

5.配置:越来越多的框架使用配置来将系统解耦.

(待续...ING...)

我在阅读过程中的思考痕迹:

1.应用程序本来就是一系列类相互调用而形成的,如果为了解耦而让每个类与其factory同时出现,岂不是让应用规模大了一倍?!!什么时候要解耦,什么时候可以忽略耦合...?!

2.EJB曾经让我很苦恼,因为每一个应用服务都要求配套有四个接口和一个实现类....那么..为什么要使用如此丑陋的框架?为什么有那么多人在疯狂地追捧着EJB?! 为什么一提到企业级应用就想到EJB?!