论java架构设计
软件架构
作为一个概念，体现在技术
和业务
两
个方面。
从技术角度来说
：软件架构随着技术的革新不断地更新其内容，软件架构建立于当前技术
和一些基
本原则
的基础之上。
先说一些基本原则
：
分层原则
：分层是为了降低软件深度复杂性而使用的关键思想，就像社会有了阶级一样，软件有了层次结构。
模块化原则
：模块化是化解软件广度复杂的必然手段，模块化的目的就是让软件分工。
接口实现分离原则
随着软件模块化的不断深入改进，面向接口编程而不是面向实现编程可以让复杂度日趋增高的软件降低模块
之间的耦合度，从而让各模块更轻松改进。从这个原则出发，软件也从微观进行了细致的规范化。
还有两个比较小但很重要的原则：
细节隐藏原则
很显然把复杂问题简化，把难看的细节隐去，能让软件结构更清晰。其实这个原则使用很普
遍，java/c++语言中的封装原则以及设计模式中的Facade（外观）模式就很能体现这个原则的精神。
依赖倒置原则
随着软件结构的进一步发展,层与层之间、模块与模块之间的依赖逐渐加深，而层、模块的动态可插拔要求不端
增大。依赖倒置原则可看视为接口实现分离原则的深化，根据此原则的精神，软件进入了工具时代。这个原则有点类似于知名的好莱坞法则：Don't call
us, we'll call you。
以上这些原则奠定了我们的软件架构的价值指标。但软件架构毕竟是建立在当前技术之上的。而每一代技术都有架构模式。过去的不再说了，让我们现在就来
看一下当前流行的技术，以及当前我们能采用的架构。
因为面向对象是当前最流行开发技术，且设计模式的大量使用使面向对象的走向成熟，而数据库是当前最有效的存储结构、web界面是当前最流行的用户接
口，所以当前最典型的三层次架构就架构在以上几项技术的基础之上，用数据库作存储层、用面向对象来实现业务层、用web来作为用户接口层。我们从三层次架
构谈起：
因为面向对象技术和数据库技术不适配，所以在标准三层次架构的基础上，我们增加了数据持久层，来管理O-R双向映射，但目前一直没有最理想的实现技术。
cmp和entity
bean技术因为其实现复杂，功能前景有限，已接近被淘汰的边缘。JDO及hibernate作为o-r映射的后期之秀，尤其是hibernate，功能
相当完备。推荐作为持久层的首选
在业务层,因为当前业务日趋负载，且变动频繁，所以我们必须有足够敏捷的技术来保证我们的适应变化的能力，在标准j2ee系统中session
bean负责业务处理，且有不
相关文档：
GOF：运用共享技术有效地支持大量细粒度的对象。
解释一下概念：也就是说在一个系统中如果有多个相同的对象，那么只共享一份就可以
了，不必每个都去实例化一个对象。比如说（这里引用GOF书中的例子）一个文本系统，每个字母定一个对象，那么大小写字母一共就是52个，那么就要定义
52个对象。如果有一个1M的� ......
String类中的构造函数
String(); 构造一个空字符串对象
String(byte[] bytes); 通过byte数组构造字符串对象
String(byte[] bytes,int offset,int length);通过byte数组，从offset开始，总共length长的字节构造字符串对象
String(char[] value); 通过char数组构造字符串对象
String(byte[] char,int offset,int length) ......
如果程序是单线程，执行起来不必担心此线程会被其他线程打扰，就像在现实中，同一时间只完成一件事情，可以不用担心这件事情会被其他事情打扰。但是如果程序中同时使用多线程，就好比现实中“两个人同时进入一扇门”，此时就需要控制，否则容易阻塞。为了避免多线程共享资源发生� ......
虽然经常创建多个不相同的线程来完成不相关的任务，然而有时执行的任务可能有一定联系，这样就需要使这些线程进行交互。比如有一个水塘，其中对水塘操作无非包括“进水”和“排水”，这两个行为各自代表一个线程，当水塘中没有水时，“排水”行为不能再进行� ......
首先打开命令行确定命令行的函数是否可以用，在命令行里面输入jar 如果可以用就会出现命令jar的各个参数选择规则，和一个小问题，我遇到的问题是有一个单独的class文件 没有源文件，程序要在netbean里面调用这个class文件，而我不知道netbean如何引用这个class文件了 就只好把class打包成jar了，
首先我在C盘里面建立了个� ......
