Java中的设计模式与7大原则归纳整理

Java中的设计模式与7大原则:

一、创建型模式

1、抽象工厂模式(Abstract factory pattern): 提供一个接口, 用于创建相关或依赖对象的家族, 而不需要指定具体类.

2、生成器模式(Builder pattern): 使用生成器模式封装一个产品的构造过程, 并允许按步骤构造. 将一个复杂对象的构建与它的表示分离, 使得同样的构建过程可以创建不同的表示.

3、工厂模式(factory method pattern): 定义了一个创建对象的接口, 但由子类决定要实例化的类是哪一个. 工厂方法让类把实例化推迟到子类.

4、原型模式(prototype pattern): 当创建给定类的实例过程很昂贵或很复杂时, 就使用原形模式.

5、单例了模式(Singleton pattern): 确保一个类只有一个实例, 并提供全局访问点.

6、多例模式(Multition pattern): 在一个解决方案中结合两个或多个模式, 以解决一般或重复发生的问题.

二、结构型模式

1、适配器模式(Adapter pattern): 将一个类的接口, 转换成客户期望的另一个接口. 适配器让原本接口不兼容的类可以合作无间. 对象适配器使用组合, 类适配器使用多重继承.

2、桥接模式(Bridge pattern): 使用桥接模式通过将实现和抽象放在两个不同的类层次中而使它们可以独立改变.

3、组合模式(composite pattern): 允许你将对象组合成树形结构来表现"整体/部分"层次结构. 组合能让客户以一致的方式处理个别对象以及对象组合。

4、装饰者模式(decorator pattern): 动态地将责任附加到对象上, 若要扩展功能, 装饰者提供了比继承更有弹性的替代方案.

5、外观模式(facade pattern): 提供了一个统一的接口, 用来访问子系统中的一群接口. 外观定义了一个高层接口, 让子系统更容易使用.

6、亨元模式(Flyweight Pattern): 如想让某个类的一个实例能用来提供许多"虚拟实例", 就使用蝇量模式.

7、代理模式(Proxy pattern): 为另一个对象提供一个替身或占位符以控制对这个对象

三、行为型模式

1、责任链模式(Chain of responsibility pattern): 通过责任链模式, 你可以为某个请求创建一个对象链. 每个对象依序检查此请求并对其进行处理或者将它传给链中的下一个对象.

2、命令模式(Command pattern): 将"请求"封闭成对象, 以便使用不同的请求,队列或者日志来参数化其他对象. 命令模式也支持可撤销的操作.

3、解释器模式(Interpreter pattern): 使用解释器模式为语言创建解释器.

4、迭代器模式(iterator pattern): 提供一种方法顺序访问一个聚合对象中的各个元素, 而又不暴露其内部的表示.

5、中介者模式(Mediator pattern) : 使用中介者模式来集中相关对象之间复杂的沟通

和控制方式.

6、备忘录模式(Memento pattern): 当你需要让对象返回之前的状态时(例如, 你的用户请求"撤销"), 你使用备忘录模式.

7、观察者模式(observer pattern): 在对象之间定义一对多的依赖, 这样一来, 当一个对象改变状态, 依赖它的对象都会收到通知, 并自动更新.

8、状态模式(State pattern): 允许对象在内部状态改变时改变它的行为, 对象看起来好象改了它的类.

9、策略模式(strategy pattern): 定义了算法族, 分别封闭起来, 让它们之间可以互相替换, 此模式让算法的变化独立于使用算法的客户.

10、模板方法模式(Template pattern): 在一个方法中定义一个算法的骨架, 而将一些步骤延迟到子类中. 模板方法使得子类可以在不改变算法结构的情况下, 重新定义算法中的某些步骤.

11、访问者模式(visitor pattern): 当你想要为一个对象的组合增加新的能力, 且封装并不重要时, 就使用访问者模式。

七大设计原则：

1、单一职责原则【SINGLE RESPONSIBILITY PRINCIPLE】：一个类负责一项职责.

2、里氏替换原则【LISKOV SUBSTITUTION PRINCIPLE】：继承与派生的规则.

3、依赖倒置原则【DEPENDENCE INVERSION PRINCIPLE】：高层模块不应该依赖低层模块，二者都应该依赖其抽象；抽象不应该依赖细节；细节应该依赖抽象。即针对接口

4、接口隔离原则【INTERFACE SEGREGATION PRINCIPLE】：建立单一接口，不要建立庞大臃肿的接口，尽量细化接口，接口中的方法尽量少.

5、迪米特法则【LOW OF DEMETER】：低耦合，高内聚.

6、开闭原则【OPEN CLOSE PRINCIPLE】：一个软件实体如类、模块和函数应该对扩展开放，对修改关闭.

7、组合/聚合复用原则【Composition/Aggregation Reuse Principle(CARP) 】

希望本篇文章对您有帮助

赞 (0)

相关推荐

  • Java设计模式之单例模式详解

    Java设计模式之单例模式详解

    单例模式是非常常见的设计模式,其含义也很简单,一个类给外部提供一个唯一的实例.下文所有的代码均在github 源码整个项目不仅仅有设计模式,还有其他JavaSE知识点,欢迎Star,Fork 单例模式的UML图 单例模式的关键点 通过上面的UML图,我们可以看出单例模式的特点如下: 1.构造器是私有的,不允许外部的类调用构造器 2.提供一个供外部访问的方法,该方法返回单例类的实例 如何实现单例模式 上面已经给出了单例模式的关键点,我们的实现只需要满足上面2点即可.但是正因为单例模式的实现方式比较

  • java设计模式之观察者模式学习

    java设计模式之观察者模式学习

    1.什么是观察者模式 简单情形:有A.B.C.D等四个独立的对象,其中B.C.D这三个对象想在A对象发生改变的第一时间知道这种改变,以便做出相应的响应或者对策. 上面的这种情形,就是观察者模式. 当然可以有多个观察者,多个被观察者. 观察者与被观察者也不是对立的,一个对象可以观察其他对象,也可以被其他对象观察. 2.观察者模式的应用 为了更好的理解什么是观察者模式,下面我举一些可能用到该模式的情形或例子: (1)周期性任务.比如linux中的周期性任务命令crontab命令,win7下的定时关机

  • java设计模式之适配器模式（Adapter）

    java设计模式之适配器模式（Adapter）

    概述 将一个类的接口转换成用户希望的另外一个接口,Adapter模式使得原本由于接口不兼容而不能一起工作的那些类可以在一起工作. 两种实现方式 1.类的适配器模式: 2.对象的适配器模式: 类的适配器模式的UML图,如下: 类的适配器模式把适配的类的API转换成为目标类的API. 上图设计的角色有: 目标角色(Target):这就是所期待得到的接口. 源角色(Adapee):现在需要适配的接口. 适配器角色(Adapter):是本模式的核心,适配器把源接口转换成目标接口. 代码示例: inter

  • java设计模式之装饰器模式（Decorator）

    java设计模式之装饰器模式（Decorator）

    概述 装饰模式是对客户端以透明的方式扩展对象的功能,是继承关系的一个替代方案.也就是说,客户端并不会觉得对象在装饰前和装饰后有什么不同,装饰模式可以在不用创造更多子类的情况下,将对象的功能加以扩展,装饰模式的关键在于这种扩展是完全透明的. 模式的结构 UML类图: 装饰模式中的类角色: 抽象构件角色(Project):给出一个接口,以规范准备接收附加责任的对象 具体构件角色(Employe):定义一个将要接收附加责任的类 装饰角色(Manager):持有一个构件对象的实例,并定义一个与抽象构件接

  • 浅谈Java设计模式之开放封闭原则

    写在前面 最近, 接手了一个新业务,系统的架构可圈可点.但有些地方让人望而生畏,有些代码臃肿难以维护,让人不敢恭维.于是,结合了Java的开放封闭原则,对其中一部分代码进行了重构优化. 先来看下以前系统的老代码 ShareChannelManager.java public ResultDO<String> shareChannel(int shareCode) { if(ShareCodeUtil.share2A(shareCode)) { // TODO, 分享到A渠道的业务逻辑代码 }

  • java 设计模式之单例模式

    java  设计模式之单例模式 前言: 在软件开发过程中常会有一些对象我们只需要一个,如:线程池(threadpool).缓存(cache).对话框.偏好设置等.这些对象如果制造出多个实例的话可能会导致一些不必要的麻烦,如:程序行为异常.资源使用过量等.这时单例模式就可以确保一个类只有一个实例,并提供全局访问点.下面是从简单的单例类来探讨该用何种方法实现单例模式. /** * 最经典的单例类 */ public class Singleton { // 设置成静态变量来记录Singleton的唯

  • java设计模式之外观模式(Facade)

    java设计模式之外观模式(Facade)

    概述 外部与内部子系统通信时必须通过的一个统一的外观模式对象进行,就是外观模式,也称门面模式.一般而言,Facade模式是为了降低客户端与实现化层之间的依赖性.外观模式的用意是为子系统提供一个集中化和简化的沟通渠道. UML类图 在上面的UML图中,出现三个角色: 客户端角色(Client):用户通过客户端来调用外观模式的类,从而来操作子系统: 外观角色(Facade):客户端可以调用这个类,此类中包含了调用子系统中具体的功能: 子系统角色(Module):定义了子系统中具体的单个功能: 代码示

  • Java中的设计模式与7大原则归纳整理

    Java中的设计模式与7大原则: 一.创建型模式 1.抽象工厂模式(Abstract factory pattern): 提供一个接口, 用于创建相关或依赖对象的家族, 而不需要指定具体类. 2.生成器模式(Builder pattern): 使用生成器模式封装一个产品的构造过程, 并允许按步骤构造. 将一个复杂对象的构建与它的表示分离, 使得同样的构建过程可以创建不同的表示. 3.工厂模式(factory method pattern): 定义了一个创建对象的接口, 但由子类决定要实例化的类是

  • 浅谈java中OO的概念和设计原则(必看)

    一．OO(面向对象)的设计基础 面向对象(OO):就是基于对象概念,以对象为中心,以类和继承为构造机制,充分利用接口和多态提供灵活性,来认识.理解.刻划客观世界和设计.构建相应的软件系统.面向对象的特征:虽然各种面向对象编程语言相互有别,但都能看到它们对面向对象基本特征的支持, 即 "抽象.封装.继承.多态" : – 抽象,先不考虑细节 – 封装,隐藏内部实现 – 继承,复用现有代码 – 多态,改写对象行为 面向对象设计模式:是"好的面向对象设计",所谓"

  • Java中为什么ArrayList初始化容量大小为10

    目录 背景 为什么HashMap的初始化容量为16? ArrayList的初始化容量是10吗? 为什么ArrayList的初始化容量为10? 小结 背景 看ArrayList源码时,无意中看到ArrayList的初始化容量大小为10,这就奇怪了!我们都知道ArrayList和HashMap底层都是基于数组的,但为什么ArrayList不像用HashMap那样用16作为初始容量大小,而是采用10呢? 于是各方查找资料,求证了这个问题,这篇文章就给大家讲讲. 为什么HashMap的初始化容量为16?

  • 详解java中面向对象设计模式类与类的关系

    详解java中面向对象设计模式类与类的关系

    前言 在java以及其他的面向对象设计模式中,类与类之间主要有6种关系,他们分别是:依赖.关联.聚合.组合.继承.实现.他们的耦合度依次增强. 1. 依赖(Dependence) 依赖关系的定义为:对于两个相对独立的对象,当一个对象负责构造另一个对象的实例,或者依赖另一个对象的服务时,这两个对象之间主要体现为依赖关系.定义比较晦涩难懂,但在java中的表现还是比较直观的:类A当中使用了类B,其中类B是作为类A的方法参数.方法中的局部变量.或者静态方法调用.类上面的图例中:People类依赖于Bo

  • Java中使用内存映射实现大文件上传实例

    在处理大文件时,如果利用普通的FileInputStream 或者FileOutputStream 抑或RandomAccessFile 来进行频繁的读写操作,都将导致进程因频繁读写外存而降低速度.如下为一个对比实验. 复制代码 代码如下: package test; import java.io.BufferedInputStream;  import java.io.FileInputStream;  import java.io.FileNotFoundException;  import

  • Java中转换器设计模式深入讲解

    Java中转换器设计模式深入讲解

    前言 在这篇文章中,我们将讨论 Java / J2EE项目中最常用的  Converter Design Pattern.由于Java8 功能不仅提供了相应类型之间的通用双向转换方式,而且还提供了转换相同类型对象集合的常用方法,从而将样板代码减少到绝对最小值.我们使用Java8 功能编写了此模式的源代码. 目的 转换器设计模式的目的是为相应类型之间的双向转换提供一种通用的方式,允许类型无需彼此了解的简洁的实现.此外,转换器设计模式引入了双向收集映射,将样板代码减少到最小. 源代码 转换器设计模式

  • Java中StringBuilder字符串类型的操作方法及API整理

    Java中StringBuilder字符串类型的操作方法及API整理

    0.StringBuilder类型简介 StringBuilder类型是一个可变的字符串类型,StringBuilder类型的API与StringBuffer类型的API基本一致,唯一的区别是StringBuilder的使用假设在单一线程中,换句话说,StringBuilder是线程不安全的.StringBuilder在实例化的时候,通常也会默认设定一个容量大小,一般为字符串参数的长度+16.StringBuilder是继承AbstractStringBuilder这个抽象类的,而这个抽象类的内

  • Java设计模式常用的七大原则总结

    Java设计模式常用的七大原则总结

    一.设计模式常用的七大原则 单一职责原则:一个类应该只负责一项职责 接口隔离原则:客户端不应该依赖它不需要的接口,即一个类对另一个类的依赖应该建立在最小的接口上 依赖倒转原则 里氏替换原则 开闭原则 迪米特法则 合成复用原则 二.单一职责原则 1. 单一职责原则注意事项和细节 降低类的复杂度,一个类只负责一项职责 2.提高类的可读性,可维护性 3.降低变更引起的风险 4.通常情况下,我们应当遵守单一职责原则,只有逻辑足够简单,才可以在代码级违反单一职责原则:只有类中方法数量足够少,可以在方法级别

  • Java设计模式之迪米特原则精解

    Java设计模式之迪米特原则精解

    目录 1.什么是迪米特原则? 2.违反迪米特原则代码案例 3.遵守迪米特原则代码案例 4.迪米特原则的注意事项 1.什么是迪米特原则? 一个对象应该对其他对象保持最少的了解. 类与类关系越密切,耦合度越大. 迪米特法则(Demeter Principle)又叫最少知道原则,即一个类对自己依赖的类知道的越少越好.也就是说,对于被依赖的类不管多么复杂,都尽量将逻辑封装在类的内部.对外除了提供的public方法,不对外泄露任何信息. 迪米特法则还有个更简单的定义:只与直接的朋友通信. 直接的朋友:每个

  • Java设计模式之单一职责原则精解

    Java设计模式之单一职责原则精解

    1.什么是单一职责原则? 首先我们可以对某个类来说,即一个类应该只负责一项职责.如类A负责两个不同职责: 职责1,职责2.当职责1需求变更而改变A时,可能造成职责2执行错误,所以需要将类A的粒度分解为A1,A2. 我们来看下面这段代码: package com.szh.principle.singleresponsibility; /** * 交通工具类 * 方式1 * 1. 在方式1的run方法中,违反了单一职责原则 * 2. 解决的方案非常的简单,根据交通工具运行方法不同,分解成不同类即可

随机推荐