设计模式
原创者：文思
一、设计原则
设计模式的目的：代码重用性、可读性、维护性
设计模式七大原则：
单一职责原则
接口隔离原则
依赖倒转原则
里氏替换原则
开闭原则原则
迪米特法则
合成复用原则
以上所有原则为了实现两个核心目标：
低耦合、高内聚；可读性、扩展性、复用性
1、单一职责原则：
一个类只应该负责一项职责。如类A负责两个不同职责：职责1、职责2，当职责1需求变化而修改A时，可能造成职责2执行错误，所以A类的粒度要分为A1和A2两个类
案例：
public classSingleResponsibility {
public static void main(String[] args) {
JiaoTongt = new RoadJiaoTong();
t.run("汽车");
}
}
interface JiaoTong{
public void run(String name);
}
class RoadJiaoTong implements JiaoTong{
@Override
public void run(String name) {
System.out.println(name + "...在公路上跑");
}
}
class WaterJiaoTong implements JiaoTong{
@Override
public void run(String name) {
System.out.println(name + "...在水中游");
}
}
RoadJiaoTong与WaterJiaoTong是拆分出来的两个类。
单一指责原则注意事项：
降低类的复杂度，一个类只负责一项职责
提高类的可维护性、降低变更引起的风险
通常情况下，只有逻辑足够简单时才可以在代码级违反单一职责原则，即只有类中方法数量足够少时，可以在方法级别保持单一职责原则。
2、接口隔离原则
客户端不应该依赖它不需要的接口，即一个类对另一个类的依赖应该建立在最小的接口上。
A通过接口依赖B，但A只使用接口中的1,2,3
C通过接口依赖D，但C只使用接口中的3,4,5
接口Interface1对于类A和类C来说不是最小接口，因为类B和类D必须去实现他们不需要的方法。
按隔离原则应当这样处理：将接口Interface1拆分为独立的几个接口，类A和类C分别与他们需要的接口建立依赖关系。也就是采用接口隔离原则。
3、依赖倒转原则
高层模块不应该依赖底层模块，二者都应该依赖其抽象。
抽象不应该依赖细节，细节应该依赖抽象。
依赖倒转的中心思想是面向接口编程。
设计理念：相对于细节的多变性，抽象的东西要稳定，以抽象为基础搭建的架构比以细节为基础的架构要稳定。接口的目的是定义好规范而不涉及到具体操作，把展现细节的任务交给实现类去完成。
反面案例：
//完成person接收消息的功能
//问题1:如果要获取微信,qq等msg,在新增类的同时Person也要增加相应的接收方法
//解决思路:引入抽象接口IReceiver,Person中使用IRceiver,Email和Mobile都实现此接口
class Person{
public void receive(Email email) {
System.out.println(email.getMsg());
}
}
class Email{
public String getMsg() {
return "this is a email mwg";
}
}
class Mobile{
public String getMsg(){
return "this is a mobile";
}
}
优化案例：将对细节Email的依赖改为对抽象接口的依赖
public classDependecyInversion {
public static void main(String[] args) {
Personp = new Person();
IReceiverreciver= newEmail();
p.receive(reciver);
}
}
//调用方
class Person{
public void receive(IReceiver reciver){//接口方式传递依赖
System.out.println(reciver.getMsg());
}
}
interface IReceiver{
StringgetMsg();
}
class Email implements IReceiver{
@Override
public String getMsg() {
return "this is a email mwg";
}
}
class Mobile implements IReceiver{
@Override
public String getMsg(){
return "this is a mobile";
}
}
依赖关系传递的三种方式：
1、接口传递 2、构造方法传递 3、setter方式传递
接口传递方式如上。
构造方式传递：
public classDependecyInversion {
public static void main(String[] args) {
IReceiverreciver= newEmail();
Personp = new Person(reciver);
p.receive();
}
}
class Person{
private IReceiver reciver;
//构造器方法传递
public Person(IReceiver reciver) {
this.reciver = reciver;
}
public void receive() {
System.out.println(reciver.getMsg());
}
}
interface IReceiver{
StringgetMsg();
}
class Email implements IReceiver{
@Override
public String getMsg() {
return "this is a email mwg";
}
}
setter方式传递：
public classDependecyInversion {
public static void main(String[] args) {
IReceiverreciver= newEmail();
Personp = newPerson();
p.setIReceiver(reciver);
p.receive();
}
}
class Person{
private IReceiver reciver;
//构造器方法传递
public Person() {
this.reciver = reciver;
}
public void receive() {
System.out.println(reciver.getMsg());
}
public void setIReceiver(IReceiver reciver) {
this.reciver = reciver;
}
}
interface IReceiver{
StringgetMsg();
}
class Email implements IReceiver{
@Override
public String getMsg() {
return "this is a email mwg";
}
}
低层模块尽量都要有接口，这样程序稳定性更好，变量的声明尽量是接口。继承时遵守里氏替换原则。
4、里氏替换原则：
如果对每个类型为T1的对象o1，都有类型为T2的对象o2，使得以T1定义的所有程序P在所有的对象o1都代换成o2时，程序P的行为没有发生变化，那么类型T2是类型T1的子类型。换句话说，所有引用基类的地方必须能透明地使用其子类的对象。在使用继承时，遵循里氏替换原则，在子类中尽量不要重写父类的方法。里氏替换原则告诉我们，继承实际上让两个类耦合性增强了，在适当的情况下，可以通过聚合，组合，依赖来解决问题(做法是：原来的父类和子类都继承一个更通俗的基类，原有继承关系去掉，采用依赖，聚合，组合等关系代替)。
5、开闭原则:
1)开闭原则（Open Closed Principle）是编程中最基础、最重要的设计原则
2)一个软件实体如类，模块和函数应该对扩展开放(对提供方)，对修改关闭(对使用方)。用抽象构建框架，用实现扩展细节。
3)当软件需要变化时，尽量通过扩展软件实体的行为来实现变化，而不是通过修改已有的代码来实现变化。
4)编程中遵循其它原则，以及使用设计模式的目的就是遵循开闭原则
错误示范：
//调用方
class GraphicEditor {
//调用方,这里错误的将实现细节放到了调用方
public void drawShape(Shape s) {
if (s.m_type == 1)
drawRectangle(s);
else if (s.m_type == 2)
drawCircle(s);
else if (s.m_type == 3)//调用方也要修改:新增扩展(三角形)
drawTriangle(s);
}
//画
public void drawRectangle(Shape r) {
System.out.println("123 ");
}
public void drawCircle(Shape r) {
System.out.println("123");
}
public void drawTriangle(Shape r) {
System.out.println(" 123");
}
}
//Shape
class Shape {
int m_type;
}
class Rectangle extends Shape {
Rectangle(){
super.m_type = 1;
}
}
class Circle extends Shape {
Circle(){
super.m_type = 2;
}
}
//新增扩展(三角形)
class Triangle extends Shape {
Triangle(){
super.m_type = 3;
}
}
以上缺点违反了设计模式的ocp原则，即对扩展开放(提供方)，对修改关闭(使用方)。即当我们给类增加新功能的时候，尽量不修改代码，或者尽可能少修改代码。比如我们这时要新增加一个图形种类三角形，我们需要做如上修改，修改的地方较多
优化案例：
//调用方,无需关注实现细节
class GraphicEditor {
//调用方无需修改
public void drawShape(Shape s) {
s.draw();
}
}
//Shape
abstract classShape {
int m_type;
public abstract void draw();
}
class Rectangle extends Shape {
Rectangle(){
super.m_type = 1;
}
//将具体的细节放到提供方
@Override
public void draw() {
// TODO Auto-generated method stub
System.out.println("123 ");
}
}
class Circle extends Shape {
Circle(){
super.m_type = 2;
}
//将具体的细节放到提供方
@Override
public void draw() {
// TODO Auto-generated method stub
System.out.println("123");
}
}
//新增扩展(三角形)
class Triangle extends Shape {
Triangle(){
super.m_type = 3;
}
//将具体的细节放到提供方
@Override
public void draw() {
// TODO Auto-generated method stub
System.out.println(" 123 ");
}
}
把创建Shape类做成抽象类，并提供一个抽象的draw方法，让子类去实现即可，这样我们有新的图形种类时，只需要让新的图形类继承Shape，并实现draw方法即可，使用方的代码就不需要修改，满足了开闭原则。
6、迪米特法则：
1)一个对象应该对其他对象保持最少的了解
2)类与类关系越密切，耦合度越大
3)迪米特法则(Demeter
Principle)又叫最少知道原则，即一个类对自己依赖的类知道的越少越好。也就是说，对于被依赖的类不管多么复杂，都尽量将逻辑封装在类的内部。对外除了提供的public 方法，不对外泄露任何信息。
4)迪米特法则还有个更简单的定义：只与直接的朋友通信
5)直接的朋友：每个对象都会与其他对象有耦合关系，只要两个对象之间有耦合关系，我们就说这两个对象之间是朋友关系。耦合的方式很多，依赖，关联，组合，聚合等。其中，我们称出现成员变量，方法参数，方法返回值中的类为直接的朋友，而出现在局部变量中的类不是直接的朋友。也就是说，陌生的类最好不要以局部变量的形式出现在类的内部。
错误案例：
//学校总部员工vo
class Employee {
private String id;
public void setId(String id) {
this.id = id;
}
public String getId() {
return id;
}
}
//学院员工vo
class CollegeEmployee {
private String id;
public void setId(String id) {
this.id = id;
}
public String getId() {
return id;
}
}
//打印学院员工的方法没有被封装到CollegeManager中
class CollegeManager {
//得到学院员工
publicList<CollegeEmployee> getAllEmployee() {
Listlist= newArrayList<CollegeEmployee>();
for (int i = 0; i < 10; i++) {
CollegeEmployeeemp= newCollegeEmployee();
emp.setId("id= " + i);
list.add(emp);
}
return list;
}
}
//SchoolManager的直接朋友有Employee\CollegeManager
//但是CollegeEmployee没有出现在成员变量或方法参数或返回值中,这就是陌生的类
class SchoolManager {
//得到学校总部员工
public List<Employee>
getAllEmployee() {
Listlist= newArrayList();
for (int i = 0; i < 5; i++) {
Employeeemp= newEmployee();
emp.setId("id= " + i);
list.add(emp);
}
return list;
}
voidprintAllEmployee(CollegeManager sub) {
//打印学院员工
//CollegeEmployee没有出现在成员变量或方法参数或返回值中,这就是陌生的类
//违反了迪米特法则
Listlist1= sub.getAllEmployee();
for (CollegeEmployee e : list1) {
System.out.println(e.getId());
}
//打印学校总部员工
Listlist2= this.getAllEmployee();
for (Employee e : list2) {
System.out.println(e.getId());
}
}
}
以上代码：SchoolManager的直接朋友Employee\CollegeManager，但是CollegeEmployee没有出现在成员变量或方法参数或返回值中,这就是陌生的类。
优化案例：
将输出学院员工的方法封装到CollegeManager中
//打印学院员工封装到CollegeManager中
class CollegeManager {
publicList<CollegeEmployee> getAllEmployee() {
Listlist= newArrayList<CollegeEmployee>();
for (int i = 0; i < 10; i++) {
CollegeEmployeeemp= newCollegeEmployee();
emp.setId("id= " + i);
list.add(emp);
}
return list;
}
//打印学院员工
public void printEmployee() {
//打印学院员工
Listlist1= getAllEmployee();
System.out.println("123");
for (CollegeEmployee e : list1) {
System.out.println(e.getId());
}
}
}
//SchoolManager的直接朋友有Employee\CollegeManager
//通过依赖CollegeManager,同时将打印学院员信息封装到CollegeManager中
class SchoolManager {
//得到学校总部员工
public List<Employee>
getAllEmployee() {
Listlist= newArrayList<Employee>();
for (int i = 0; i < 5; i++) {
Employeeemp= newEmployee();
emp.setId("id= " + i);
list.add(emp);
}
return list;
}
//打印全部员工
voidprintAllEmployee(CollegeManager sub) {
//打印学院员工,没有引入陌生类,通过依赖完成
sub.printEmployee();
//打印学校总部员工
Listlist2= this.getAllEmployee();
System.out.println("123");
for (Employee e : list2) {
System.out.println(e.getId());
}
}
}
迪米特法则的核心是降低类之间的耦合.但是注意：由于每个类都减少了不必要的依赖，因此迪米特法则只是要求降低类间(对象间)耦合关系，并不是要求完全没有依赖关系.
7、合成复用原则：
尽量使用合成/聚合的方式，而不是使用继承
二、设计模式
设计模式共分三种类型，共23种。
1、创建型模式：单例模式、抽象工厂模式、原型模式、建造者模式
2、结构型模式：适配器模式、桥接模式、装饰模式、组合模式、外观模式、享元模式、代理模式
3、行为型模式：模板方法模式、命令模式、访问者模式、迭代器模式、观察者模式、策略模式..
单例模式：
使用场景：需要频繁进行创建和销毁的对象；创建时耗时过多或资源耗费过多，但又常用到的对象；工具类对象；频繁访问火速健康或文件的对象。
采取一定的方法保证在整个软件系统中某个类只能存在一个对象实例，并且该类只提供一个取得其对象实例的方法(静态方法)
八种写法：饿汉式(静态常量)、饿汉式(静态代码块)、懒汉式(线程不安全)、懒汉式(线程安全同步代码块) 懒汉式(线程安全同步方法)、双重检查、静态内部类、枚举。
八种代码实现：
//1:饿汉式：静态常量
//优先：简单、无线程安全问题
//缺点：无懒加载效果,不使用这个实例也会装载,所以易造成内存浪费
class Singleton{
private Singleton() {
}
private final static Singleton instance = new Singleton();
public Singleton getInstance(){
return instance;
}
}
//2:饿汉式：静态代码块
//优先：同上
//缺点：同上
class Singleton1{
private static Singleton1 instance;
static {
instance = new Singleton1();
}
private Singleton1() {
}
public static Singleton1
getInstance() {
return instance;
}
}
//3:懒汉式：线程不安全
//优先：懒加载,单线程下安全
//缺点：多线程下易产生多个实例,实际开发中避免
class Singleton2{
private static Singleton2 instance;
private Singleton2() {
}
public static Singleton2
getInstance() {
if(instance == null) {
instance = new Singleton2();
}
return instance;
}
}
//4:懒汉式：同步方法
//优先：懒加载,线程安全
//缺点：每个线程要获取实例是都需要锁,多线程下效率低
class Singleton3{
private static Singleton3 instance;
private Singleton3() {
}
//缺点：每个线程要获取实例是都需要锁,多线程下效率低
public static synchronized Singleton3
getInstance() {
if(instance == null) {
instance = new Singleton3();
}
return instance;
}
//5:懒汉式：同步代码块
//优缺同上,多线程也容易都到if中产生多实例
public static Singleton3
getInstance3() {
if(instance == null) {
synchronized (Singleton3.class) {
instance = new Singleton3();
}
}
return instance;
}
}
//6双重检查
//推荐使用,线程安全效率又高
class Singleton4{
private static volatile Singleton4 instance;
private Singleton4() {
}
public static Singleton4
getInstance4() {
if(instance == null) {
synchronized (Singleton4.class) {
if(instance == null) {
instance = new Singleton4();
}
}
}
return instance;
}
}
//7静态内部类
//推荐使用
//优点：SinletonInsance这个内部类只有调用时才被装载
//类的静态属性只会在第一次加载时初始化,这里jvm帮助保证了线程安全
class Singleton5{
private Singleton5() {}
private static class SinletonInsance{
private static final Singleton5 INSTANCE = new Singleton5();
}
public static synchronized Singleton5
getInstance() {
return SinletonInsance.INSTANCE;
}
}
//8枚举实现单例模式
//推荐使用
enum Sinleton6{
INSTANCE;
public void sayOK() {
}
}
工厂模式：
Factory：工厂类，简单工厂模式的核心，它负责实现创建所有实例的内部逻辑。工厂类的创建产品类的方法可以被外界直接调用，创建所需的产品对象。
IProduct：抽象产品类，简单工厂模式所创建的所有对象的父类，它负责描述所有实例所共有的公共接口。
Product：具体产品类，是简单工厂模式的创建目标。
创建抽象产品类
public abstract class Computer{
*产品的抽象方法，由具体的产品类去实现
public abstract void start();
}
创建具体产品类
public class LenovoComputer extends Computer{
@Override
public void start() {
System.out.println("联想电脑启动");
}
public class HpComputer extends Computer{
@Override
public void start() {
System.out.println("惠普电脑启动");
}
}
创建工厂类
public class ComputerFactory {
public static Computer createComputer(Stringtype){
Computer mComputer=null;
switch (type) {
case "lenovo":
mComputer=new LenovoComputer();
break;
case "hp":
mComputer=new HpComputer();
break;
case "asus":
mComputer=new AsusComputer();
break;
}
return mComputer;
}
}
客户端调用工厂类
public class CreatComputer {
public static void main(String[]args){
ComputerFactory.createComputer("hp").start();
}
}
缺点:
系统扩展困难，一旦添加新产品就不得不修改工厂逻辑，同样破坏了“开闭原则”；在产品类型较多时，有可能造成工厂逻辑过于复杂，不利于系统的扩展和维护
适用场景：
工厂类负责创建的对象比较少：由于创建的对象较少，不会造成工厂方法中的业务逻辑太过复杂。
客户端只知道传入工厂类的参数，对于如何创建对象不关心：客户端既不需要关心创建细节，甚至连类名都不需要记住，只需要知道类型所对应的参数。
