（1）单一职责原则（SRP)
概念：类的职责单一，对外只提供一种功能，引起类变化的原因应该只有一个。如果一个类中有超过一项原则，那么应该把这些职责分离出去，再分别创建一些类来实现。
将如下 Modem.java 类改造为单一职责的类：
interface Modem {
public void dial(String pno);
public void hangup();
public void send(char c);
public void recv();
}
该接口中实现了两个职责，一个是连接管理，另一个是数据通信，应该将两个职责分离开来。
interface ModemConnection {
public void dial(String pno);
public void hangup();
}
interface ModemDataChannel {
public void send(char c);
public void recv();
}
（2） 开放封闭原则（OCP)
概念：一个软件实体应该对扩展开放，对修改关闭。也就是说当我们在设计一个模块的时候，应当使这个模块能够在不被修改的前提下扩展。
（3）里氏替换原则（LSP）
概念：任何基类出现的地方，都可以用子类进行替换。 换言之,一个软件实体如果使用的是一个基类的话,那么一定适用于其子类,而且它根本不能察觉出基类对象和子类对象的区别.只有衍生类可以替换基类，软件单位的功能才能不受影响，基类才能真正被复用，而衍生类也能够在基类的基础上增加新功能。
（4） 依赖倒置原则（DIP）
概念：程序要依赖于抽象(接口)，不要依赖具体的实现(类)，也就是针对接口编程。面向过程的开发，上层调用下层，上层依赖于下层，当下层剧烈变动时上层也要跟着变动，这就会导致模块的复用性降低而且大大提高了开发的成本。面向对象的开发很好的解决了这个问题，一般情况下抽象的变化概率很小，让用户程序依赖于抽象，实现的细节也依赖于抽象。即使实现细节不断变动，只要抽象不变，客户程序就不需要变化。这大大降低了客户程序与实现细节的耦合度。
（5）接口隔离原则（ISP）
概念：使用多个专门的接口，而不使用单一的总接口，即客户端不应该依赖那些它不需要的接口。即接口仅仅提供客户端需要的行为，客户端不需要的行为则隐藏起来，应当为客户端提供尽可能小的接口，而不要提供大的总接口。
2、工厂模式（1）简单工厂模式
是指由一个工厂对象决定创建出哪一种产品类的实例。简单工厂适用于工厂类负责创建的对象较少的场景，且客户端只需要传入工厂类的参数，对于如何创建对象的逻辑不需要关心。属于创建型设计模式。
（2）工厂方法模式
工厂方法模式（Fatory Method Pattern）是指定义一个创建对象的接口，但让实现这个接口的类来决定实例化哪个类，工厂方法让类的实例化推迟到子类中进行。在工厂方法模式中用户只需要关心所需产品对应的工厂，无须关心创建细节，而且加入新的产品符合开闭原则。
（3）抽象工厂模式
抽象工厂模式（Abastract Factory Pattern）是指提供一个创建一系列相关或相互依赖，对象的接口，无须指定他们具体的类。客户端（应用层）不依赖于产品类实例如何被创建、实现等细节，强调的是一系列相关的产品对象（属于同一产品族）一起使用创建对象需要大量重复的代码。需要提供一个产品类的库，所有的产品以同样的接口出现，从而使客户端不依赖于具体实现。
3、观察者模式（1）概念
观察者（Observer）模式的定义：指多个对象间存在一对多的依赖关系，当一个对象的状态发生改变时，所有依赖于它的对象都得到通知并被自动更新。这种模式有时又称作发布-订阅模式、模型-视图模式，它是对象行为型模式。
（2）模式结构与实现
观察者模式的主要角色如下。
- 抽象主题（Subject）角色：也叫抽象目标类，它提供了一个用于保存观察者对象的聚集类和增加、删除观察者对象的方法，以及通知所有观察者的抽象方法。
- 具体主题（Concrete Subject）角色：也叫具体目标类，它实现抽象目标中的通知方法，当具体主题的内部状态发生改变时，通知所有注册过的观察者对象。
- 抽象观察者（Observer）角色：它是一个抽象类或接口，它包含了一个更新自己的抽象方法，当接到具体主题的更改通知时被调用。
- 具体观察者（Concrete Observer）角色：实现抽象观察者中定义的抽象方法，以便在得到目标的更改通知时更新自身的状态。
（1）概念
单例模式是指一个类只有一个实例，并且这个实例是由这个类本身来创建的，单例类必须给所有其他对象提供这一实例。
（2）单例模式类型
- 饿汉式：在类加载的时候已经创建好该单例对象。
//饿汉式
public class Hungry {
private Hungry() {
}
private final static Hungry HUNGRY = new Hungry();
public static Hungry getInstance(){
return HUNGRY;
}
}
- 懒汉式：在需要使用对象的时候才会去创建对象。
//懒汉式单例
public class LazySingle {
private LazySingle(){
}
private static LazySingle lazySingle;
public static LazySingle getInstance(){
if (lazySingle == null ) {
lazySingle = new LazySingle();
}
return lazySingle;
}
}
但是这样会不会有问题呢？这样创建的懒汉式单例模式在单线程环境下肯定是没问题的，但是在多线程环境下，就会有问题了。就会不止创建一个对象了，那么如何改进呢？如下：
双重检查锁：
//懒汉式单例
public class LazySingle {
private LazySingle(){
System.out.println(Thread.currentThread().getName()+"ok");
}
private static LazySingle lazySingle;
//双重检查加锁
public static LazySingle getInstance(){
if (lazySingle == null ){
synchronized (LazySingle.class){
if (lazySingle == null ) {
lazySingle = new LazySingle();
}
}
}
return lazySingle;
}
检查变量是否被初始化(不去获得锁)，如果已被初始化立即返回这个变量。获取锁第二次检查变量是否已经被初始化：如果其他线程曾获取过锁，那么变量已被初始化，返回初始化的变量。否则，初始化并返回变量。
5、装饰器模式（1）概念
装饰器模式从字面意思来说就是对某一个事物进行装饰的一种模式。从代码层面而言，是对类的一个扩展或者是修饰，从传统方法而言，我们可以使用继承来对某一个类进行扩展，但是往往会导致会出现非常多的子类，如果我们要想避免这种情况，那么我们就可以使用设计模式中的——装饰器模式。
（2）优缺点
装饰器模式是在不改变现有对象结构的情况下，动态地给该对象增加一些职责，即增加其额外功能。
但是如果对于一个类型装饰的类的扩展功能太多，那么将会导致有很多的小类，我们在选择使用装饰器设计模式的时候要根据实际情况进行选择。
6、适配器模式适配器模式（Adapter）的定义如下：将一个类的接口转换成客户希望的另外一个接口，使得原本由于接口不兼容而不能一起工作的那些类能一起工作。适配器模式分为类结构型模式和对象结构型模式两种，前者类之间的耦合度比后者高，且要求程序员了解现有组件库中的相关组件的内部结构，所以应用相对较少些。
7、软件开发生命周期（SDLC）为了避免产生严重项目失败后果，软件开发的生命周期通常可以被划分为六个阶段：需求收集、设计、软件开发、测试和质量保证、部署、维护。
（1）需求收集：利益相关方需要将收集到的所有信息，记录到软件需求规范(Software Requirement Specification，SRS)文档中。在完成了需求收集后，开发团队需要进行可行性研究，以确定项目是否能够被完成。
（2）设计：此阶段旨在模拟软件应用的工作方式，并设计出软件蓝图。负责软件高级设计的开发人员将组成设计团队，并通过由上个阶段产生的SRS文档，来指导设计过程，并最终完成满足要求的体系结构。此处的高级设计是指包括用户界面、用户流程、通信设计等方面在内的基础要素。
（3）软件开发：在此阶段，具有不同专业知识(例如前端和后端)的开发人员或工程师，会通过处理设计的需求，来构建和实现软件。这既能够由一个人，也可以由一个大型团队来执行，具体取决于项目的规模。后端开发人员负责构建数据库结构和其他必要组件。最后，由前端开发人员根据设计去构建用户界面，并按需与后端进行对接。在配套文档方面，用户指南会被创建，源代码中也应适当地留下相应的注释。也就是说，为了保证良好的代码质量，适当的开发指南和政策也是必不可少的。
（4）测试：专门的测试人员协同开发团队在此阶段开展测试工作。测试既可以与开发同时进行，也可以在开发阶段结束时再开展。通常，开发人员在开发软件时就会进行单元测试，以便检查每个源代码单元是否能够按照预期工作。
（5）部署：完成测试后，我们就需要通过部署软件，来方便用户使用了。在此阶段，部署团队需要通过遵循若干流程，来确保部署流程的成功。无论是简单的流程，还是复杂的部署，都会涉及到创建诸如安装指南、系统用户指南等相关部署文档。
（6）维护：作为开发周期的最后阶段，维护涉及到报告并修复在测试期间未能发现的错误。在修复方式上，我们既能够采取立即纠正错误的方式，也可以将其作为常规性的软件更新。此外，软件项目团队还会在此阶段从用户处收集反馈，以协助软件的改进，并提高用户的软件使用体验。
8、六种软件开发模型（1）瀑布模型：作为最古老、也是最直接的SDLC方法，瀑布方法遵循的是线性执行顺序。如上图所示，从需求收集到维护，逐步依次推进，且不存在任何逆转或倒退的步骤。也就是说，只有当上一步完成后，才能继续下一步。
（2）迭代模型：开发界引入迭代方法作为瀑布模型的替代方案。它通过添加迭代式重复性开发周期，来克隆瀑布方法的所有步骤。由于最终产品的各个部分在完成后，才在每次迭代结束时发布的，因此这种方法也属于增量式。具体而言，迭代方法的初始阶段是计划，而最后一个阶段是部署。介于两者之间的是：计划、设计、实施、测试和评估的循环过程。
（2）敏捷法：敏捷(Agile)即为快速轻松的移动能力。以沟通和灵活性为中心的敏捷原则与方法，提倡以更短的周期和增量式地进行部署与发布。
敏捷开发是在各个“冲刺”中进行的，每个冲刺通常持续大约2到4周。每个冲刺的目标不一定是构建MVP(最小可行产品，Minimum Viable Product)，而是构建可供客户使用的软件的一小部分。其交付出来的可能只是某个功能，而非具有完全功能的产品。也就是说，交付成果可能只是一个将来能够被慢慢增加的功能性服务，而不一定是MVP。
（3）精益方法：软件开发领域的精益方法源于精益制造的原则。这种方法旨在减少生产过程中的浪费和成本，从而实现利润的最大化。该方法虽与敏捷开发类似，但是侧重于效率、快速交付、以及迭代式开发。而区别在于，敏捷方法更专注于持续沟通和协作，以体现价值;而精益方法更专注于消除浪费，以创造客户价值。
（5）螺旋方法：
作为一种具有风险意识的软件开发方法，螺旋方法侧重于降低软件开发过程中的各项风险。它属于一种迭代的开发方法，在循环中不断推进。由于结合了瀑布模型和原型设计，因此螺旋方法是最灵活的SDLC方法，并具有如下四个主要阶段：
-
第一阶段--定义项目目标并收集需求。
-
第二阶段--该方法的核心是进行全面的风险分析和计划，消减已发现的风险。产品原型会在本阶段交付出来。
-
第三阶段--执行开发和测试。
-
第四阶段--涉及评估已开发的内容，并计划开展下一次迭代。
螺旋方法主要适用于高度定制化的软件开发。此外，用户对于原型的反馈可以在迭代后期(在开发阶段)扩展各项功能。
暑期编程PK赛 得CSDN机械键盘等精美礼品！
