时间紧的第一段直接忽略：作为一个菜鸟程序员，写这么高大上的题目似乎有点言过其实，也确实不知道这篇博客会写成什么样子，但唯一可以确定的是这篇博客将会成为个人未来修改最多的一篇，毕竟写出更高质量的程序伴随着整个职业生涯的，提升就写点，不知道最后会变成什么样子呢。随着代码量的积累和对程序结构设计的认知逐渐加深，也确实亲身体会到高质量（众多同行喜欢优雅这个词汇，个人却始终觉得这个词太过ZB，我是个老实而且十分实在的人）的程序设计是多么重要，下面只是个人结合自身体会和最近读的浅显的不能再浅显的材料的一个小总结，希望以后少走弯路，提升自己代码的质量，也可以作为是提升个人修养的一部分~
结构化的软件体系结构和面向对象软件体系结构的比较随处可见，当自己比菜鸟还菜的时候没有认识到两者的区别，随着项目经验的增加，实习经历的历练，认识到一个结构化体系架构的软件系统维护起来，四个字——踩坑，吐血。最简单的一点，一个功能繁杂细节繁多的系统用结构化的思路设计比追一个冷冰冷的女神更吃力吧，追上陈妍希饰演的小龙女，哦，可能和写最简单的一个小模块差不多吧。OOA直接针对问题与中客观存在事物建立模型，用对象的属性和服务分别描述事物的静态和动态特征更贴近于我们思考与设计的方式，另外直接就能将事物之间的联系反应到设计之中是多么的轻松加愉快（据说正确的设计只有不到3%能做到，但整体脉络是清晰的呀）。OOD就针对系统的具体实现运用面向对象的方法进行设计，调整和修改了OOA中的的某些部分，彼此之间能紧密衔接，相比之下工作难度和工作量都降低的令人发指啊。OOP就更easy了，据说在印度是由留守妇女做的，看到这里的小盆友（尤其是逗琦童鞋），希望你能早日摆脱这个阶段吧，如果在贵圈混~
上面一段总结起来就是四句话：OO符合人们常规的方式（如果你承认程序员或所有IT从业者是human）;OO从设计到实现延续性好；OO可维护性好（修改一个对象内部总比在一堆高度耦合的结构化代码中挑三拣四好吧）；OO复用性好，谁叫咱又能封装又清晰呢！
（复用）类级别的复用（代码复用）以类为封装的单位，这样复用的粒度太小；组件（对一组类组合封装，完成一个或多个功能的特定服务）复用更nice些；
（体系结构）经典软件体系结构风格：
(1)管道/过滤器风格：每个处理模块作为一个组件，前面的输入传递给后端，例如unix shell。优点是组件高内聚低耦合，简单可复用，可扩展支持并行。缺点是导致进程成为批处理结构（将每个过滤器看成完整的从输入到输出的转换），不适合交互；
(2)数据抽象和面向对象风格：数据和上面的操作组合在一起封装为一个整体。
依赖：某个对象行为与另一个对象有关
多态：最大限度降低了类和程序模块之间的耦合性，使得他们不需要了解对方的具体细节，就可以很好地的共同工作。
(3)基于事件的隐式调用风格：需要添加一个组件时，向一个或多个事件注册，事件触发时由系统自动调用在这个事件中注册的所有过程。所以特点是事件的触发者并不知道哪些组件会被这些事件影响，顺序可能也无法控制，所以也有一些隐式调用的系统包含显式调用作为组件交互的补充形式。对于动态配置的应用程序尤其有用，因为在这种风格的体系结构中服务提供者易于修改，也易于使用或禁止某些功能。也可以说这种模式使得系统的演化、升级变得简单，可以在不影响其他组件的情况下替换某个组件，因为当一个组件代替另一个组件时不会影响到其他组件的接口。缺点：组件放弃了对系统进行计算的控制
(4)层次风格：每一层提供一个抽象的功能，为上一层服务，并作为下一层的用户，交互只在相邻层可见。优点：复杂的问题分解为一系列递增的步骤；扩展性好，内部对外部不可见，改变最多影响相邻的上下层；每层支持复用，每层定义标准的对外接口，同一层的不同实现可以交换使用；缺点：效率问题。通信协议空间上每层需要单独的信息头标示，时间上多一层调用，如果是远程调用效率更低。
(5)仓库风格：由中央数据结构和外部组件组成。两种：传统的数据库体系结构，由输入事务选择进行何种处理，并把结果作为当前状态存储到中央数据结构中。另一种是黑板体系结构，由中央数据结构的状态决定进行何种处理。简单的说，就是多个人共用一块黑板，另外有单独的控制机制开控制各个独立组件对黑板的访问（例如有个主持人防止他们乱抢粉笔）。NIO可以认为是黑板体系结构的变种，用处蛮大。虚拟机风格：
(6)不解释，搞java的都懂。有利于程序的可移植性性和程序语言的跨平台能力，缺点是间接层带来系统性能的下降。
(体系结构)分布式软件体系结构风格
(1)主机+仿真终端：和集中式管理类似
(2)文件共享：
1 功能分布到各个节点数据存放在文件服务器
2 功能和数据都分布到各个节点，但是把数据处理作为共享文件，可被多个节点使用。访问其他节点的数据需要先把数据调到本地，处理后返回。
缺点：传输大量数据时，数据传输会成为系统瓶颈。
(3)客户-服务器体系结构：客户端不是吧服务端的大量数据调到本地，而是向服务器发服务请求，接受处理结果。与文件共享结构的共享数据特性相比，客户-服务器结构在不同节点之间共享服务。
(4)瘦客户-服务器体系结构：解决原来结构末端客户多，分布广，不同区域需求不同（无法就近设定服务器，负载均衡也不好做），系统安装，维护，升级复杂，工作量大，而瘦客户-服务器体系结构中需求的多样化和动态变化都体现在服务器上，服务器发布新版本，各地用户下载即可，便于管理。
两层C/S体系结构风格
明显的区分服务器与客户机，提供给多个节点共享的公共服务集中在服务器上，客户机只配备与本地业务处理相关的功能和数据。优点：有利于分布式的数据组织，组件间位置透明，客户和服务器不用考虑对方位置，扩展性好，便于服务器修改，增加。
缺点：难以管理大量客户机，客户端程序直接访问数据库服务器，客户端计算机其他程序也可以想办法访问数据库，安全性低
三层C/S体系结构风格
数据服务器（存储管理系统共享的数据，提供查询，更新，一致性维护），应用服务器（按应用系统需求和业务逻辑，为业务处理提供服务，相对于客户端是服务器，相对于数据服务器是客户端），客户端。可以分为表示层，功能层和数据层，表示层和功能层之间的数据交互要尽量简洁。
与两层C/S体系结构风格相比，优点：提高系统和软件的可维护，可扩展性；隔离表示层与数据层，安全。设计时要考虑三层间的通信方法，通信频度和数据量。
BS体系结构数据查询的响应速度远远低于C/S体系结构。另外C/S经常在局域网，B/S在广域网。
混用B/S与C/S架构：
第一种：内部用户通过局域网直接访问数据库服务器，采用C/S架构，外部用户通过Internet访问数据库，再通过web服务器访问数据服务器，是B/S架构。
第二种：不论内部外部用户，修改和维护数据操作用C/S架构，查询和浏览操作采用B/S架构。
软件设计的目标：正确性，健壮性（出现错误也能正常运行），高效性（时间，空间效率），可复用性（方便的移植到其他应用中），可维护性（容易进行修改）。
代码段1：
class Cal{
public static void main(String[] args){
BufferedReader b = new BufferedReader(new InputStreamReader(System.in));
System.out.println("请输入数字A");
String A = b.readLine();
System.out.println("请输入数字B");
String B = b.readLine();
int C = (new Integer(A)).intValue() / (new Integer(B)).intValue();
System.out.println("A/B = " + C)；
}
}
特点：正确；输入有错程序终止，不健壮；是专门为特殊问题制定的，不能作为整体复用；修改困难，加一个加法功能，会发现增加功能需要修改原来的类，违背开闭原则（扩展开放，修改修改关闭）；
代码段 2：
class Cal{
private static String getAnInputFromUser(){
try{
BufferedReader b = new BufferedReader(new InputStreamReader(System.in));
return (b.readLine());
}catch(IOException e){
System.out.println(e);
return " ";
}
}
public static void main(String[] args){
System.out.println("请输入数字A");
String A = getAnInputFromUser();
System.out.println("请输入数字B");
String B = getAnInputFromUser();
while(!A.equals("stop") && !B.equals("stop")){
try{
int a = (new Integer(A)).intValue();
int b = (new Integer(B)).intValue();
int c = a/b;
System.out.println("A/B = " + c);
}catch(Exception e){
System.out.println("incrrect ,try again..");
}
System.out.println("请输入数字A");
A = getAnInputFromUser();
System.out.println("请输入数字B");
B = getAnInputFromUser();
}
}
}
特点：正确；输入有错程序正常运行，健壮；是专门为特殊问题制定的，不能作为整体复用；修改困难，加一个加法功能，会发现增加功能需要修改原来的类，违背开闭原则（扩展开放，修改修改关闭）；
下面说一下类的复用：复用可以在一个项目的不同地方甚至另一个项目中重复使用，可以从代码，类，相关类聚合（组件，java.awt包），设计模式，框架，体系结构等多个方面实现复用；对于一个设计好的类可以通过继承，聚合，依赖等技术实现复用（如何实现？）。另外通过减少类的耦合性可以增加复用性（想想问什么？A与B耦合，没有B就不可以使用A，降低A的复用性，使用中介者模式会减少这种耦合）。
参考内容：
《软件设计与体系结构》 刘其成 主编