设计模式
设计模式描述了软件设计过程中某一类常见问题的一般性的解决方案。面向对象设计模式描述了面向对象设计过程中,特定场景下,类与相互通信的对象之间常见的组织关系。每一个模式描述了一个在我们周围不断重复发生的问题，以及该问题的解决方案的核心。设计模式不是工具，它是软件开发的哲学，它能知道你如何去设计一个优秀的架构，编写有单健硕的代码，解决一个复杂的问题。因为它是软件行业的经验总结，因此它具有更广泛的适应性，不管你使用什么编程语言，不管你遇到什么业务，设计模式都可以自由“入侵”。所有编程初学者都会有这样的问题，就是碰到问题就直觉地用计算机能够理解的逻辑来描述和表达待解决的问题及具体的求解过程。这其实是用计算机的方式去思考，比如计算器这个程序，先要求输入两个数和运算符号，然后根据运算符号判断选择如何运算，得到结果，这本身没有错，但这样的思维却使得我们的程序只为满足实现当前的需求，程序不容易维护，不容易扩展，更不容易复用。从而达不到高质量代码的要求，所以就需要设计容易维护，容易扩展，又容易复用的代码程序。因此我们就开始考虑通过封装、继承、多态把程序的耦合度降低，使用设计模式使得程序更加的灵活，容易修改，并且易于复用。这样就可以是我们设计的代码程序能够更加简单，方便。面向对象设计模式解决的是"类与相互通信的对象之间的组织关系,包括它们的角色,职责 ,协作方式几个方面"。面向对象设计模式是"好的面向对象设计",所谓"好的面向对象设计"是那些可以满足"应对变化,提高复用"的设计。面
面向对象设计和面向对象设计原则
向对象设计模式描述的是软件设计,因此它是独立于编程语言的，但是面向对象设计模式的最终实现仍然要使用面向对象编程语言来表达。面向对象设计模式不像算法技巧可以照搬照用,它是建立在对"面向对象"纯熟,深入的理解的基础上的经验性认识.掌握面向对象设计模式的前提是首先掌握"面向对象"!
单一职业原则：
该原则中，一个类只负责一项职责，虽然单一职责原则比较简单，并且被认为是常识，但是即便是经验丰富的程序员写出的程序，也会有违背这一原则的代码存在。为什么会出现这种现象呢？因为有职责 扩散。所谓职责扩散，就是因为某种原因，职责P被分化为粒度更细的职责P1和P2。所以记住，在职责扩散到我们无法控制的程度之前，立刻对代码进行重构。
里氏转换原则：
该原则通俗讲就是，子类可以扩展父类的功能，但不能改变父类原有的功能。再详细点就是：子类可以实现父类的抽象方法，但不能覆盖父类的非抽象方法。子类中可以增加自己特有的方法。当子类的方 法重载父类的方法时，方法的前置条件（即方法的形参）要比父类方法的输入参数更宽松。当子类的方法实现父类的抽象方法时，方法的后置条件（即方法的返回值）要比父类更严格。
依赖倒置原则：
高层模块不应该依赖低层模块，二者都应该依赖其抽象；抽象不应该依赖细节；细节应该依赖抽象。依赖倒置原则基于这样一个事实：相对于细节的多变性，抽象的东西要稳定的多。以抽象为基础搭建起 来的架构比以细节为基础搭建起来的架构要稳定的多。在java中，抽象指的是接口或者抽象类，细节就是具体的实现类，使用接口或者抽象类的目的是制定好规范和契约，而不去涉及任何具体的操作，把 展现细节的任务交给他们的实现类去完成。
接口隔离原则：
客户端不应该依赖它不需要的接口；一个类对另一个类的依赖应该建立在最小的接口上。接口隔离原则注重对接口依赖的隔离。接口隔离原则主要约束接口，主要针对抽象，针对程序整体框架的构建。
迪米特原则：
一个对象应该对其他对象保持最少的了解。因为类与类之间的关系越密切，耦合度越大，当一个类发生改变时，对另一个类的影响也越大。所以要尽可能的降低类与类之间的耦合度
开闭原则：
一个软件实体如类、模块和函数应该对扩展开放，对修改关闭。
UML
统一建模语言(UML）是一种直观化、明确化、构建和文档化软件系统产物的通用可视化建模语言。它捕捉了被构建系统的有关决策和理解，用来理解、设计、浏览、配置、维护以及控制系统的信息。统一建模语言(UML）是一种直观化、明确化、构建和文档化软件系统产物的通用可视化建模语言。它捕捉了被构建系统的有关决策和理解，用来理解、设计、浏览、配置、维护以及控制系统的信息。UML可以与所有的开发方法、生命阶段、应用领域和媒介一同使用。它意图统一过去建模技术的经验，将当前软件最佳实践合并至标准的方法。UML包括语义概念、标记符号和指南，具有静态、动态、环境上的和组织性的部分。它可以被具有代码产生和报表生成的交互式可视建模工具所支持。UML不是编程语言。工具可以提供UML至各种编程语言的代码生成，以及可以从现有的程序逆向构筑模型。UML 不是用于定理证明的高度正式的语言。
UML视图
视图在最高层次可以划分为三个领域:结构性分类、动态行为和模型管理。
结构性分类描述了系统中的事物和事物间的关系。分类包括类、用例、构件和结点。分类提供了动态行为构建的基础。分类视图包括静态视图、用例视图和实现视图。
动态行为描述了系统时间上的行为。行为可以用静态视图中系统快照的一系列变更来描述。行为视图包括状态机图、活动图和交互图。
模型管理描述了用层次式的单元对模型自身的组织。包是模型的通用组织单元。特殊的包包括模型和子系统。模型管理视图与其它视图相交迭，为团队工作和配置控制把它们组织起来。
UML的各种概念和结构并不存在明显的界线,但为了方便,我们将它们划分至多个视图。视图是表达系统单个方面的UML建模结构的简单子集。
静态视图：
静态视图对应用领域的概念建模，以及将内建的概念作为应用实现的一部分。该视图描述时间相关的行为，因而是静态的。时间相关的行为由其它视图描述。静态视图的主平组成部分是类和关系:关联、继承和各种依赖，如实现和使用。类是对应用领域或应用案概念的描述。类视图围绕着类组织;其它元素属于或附加于类。静态视图显示为类图,名称的由来是因为它们主要的重点是类的描述。
用例视图：
用例视图对外部用户――称为活动者―—所感知的系统功能进行建模。用例是用活动者和系统之间的交互来表达、条理分明的功能单元。用例视图的目的是列举活动者和用例,显示活动者在每个用例中的参与情况。
UML的概念范围
1.静态结构
2.动态行为
3.实现构造
4.模型组织
5.扩展机制