为什么我的AD16不同网络也可以链无法连接到wifi网络一起

使用clone,发送十个邮件

原型模式的本質就是clone可以解决构建复杂对象的资源消耗问题,能再某些场景中提升构建对象的效率;还有一个重要的用途就是保护性拷贝可以通过返回一个拷贝对象的形式,实现只读的限制

适配器模式、装饰器模式、代理模式、外观模式、桥接模式、组合模式、享元模式。

定义: 適配器模式将某个类的接口转换成客户端期望的另一个接口表示目的是消除由于接口不匹配所造成的类的兼容性问题。

主要分为三类:類的适配器模式、对象的适配器模式、接口的适配器模式

通过多重继承目标接口和被适配者类方式来实现适配

举例(将USB接口转为VGA接口),类圖如下:

Projector将USB映射为VGA只有VGA接口才可以连接上投影仪进行投影

5.2 对象适配器模式
对象适配器和类适配器使用了不同的方法实现适配,对象适配器使用组合类适配器使用继承。

举例(将USB接口转为VGA接口)类图如下:

实现VGA接口,表示适配器类是VGA类型的适配器方法中直接使用USB对象。

5.3 接ロ适配器模式

当不需要全部实现接口提供的方法时可先设计一个抽象类实现接口,并为该接口中每个方法提供一个默认实现(空方法)那么该抽象类的子类可有选择地覆盖父类的某些方法来实现需求,它适用于一个接口不想使用其所有的方法的情况

举例(将USB接口转为VGA接ロ,VGA中的b()和c()不会被实现)类图如下:

总结一下三种适配器模式的应用场景:

类适配器模式:当希望将一个类转换成满足另一个新接口的类時,可以使用类的适配器模式创建一个新类,继承原有的类实现新的接口即可。

对象适配器模式:当希望将一个对象转换成满足另一個新接口的对象时可以创建一个Wrapper类,持有原类的一个实例在Wrapper类的方法中,调用实例的方法就行

接口适配器模式:当不希望实现一个接口中所有的方法时,可以创建一个抽象类Wrapper实现所有方法,我们写别的类的时候继承抽象类即可。

我个人理解三种命名方式,是根據 src是以怎样的形式给到Adapter(在Adapter里的形式)来命名的

类适配器,以类给到在Adapter里,就是将src当做类继承,

对象适配器以对象给到,在Adapter里將src作为一个对象,持有

接口适配器,以接口给到在Adapter里,将src作为一个接口实现。

根据合成复用原则组合大于继承。因此类的适配器模式应该少用。

定义:动态的将新功能附加到对象上在对象功能扩展方面,它比继承更有弹性

6.1 装饰者模式结构图与代码示例

定义一個对象接口,可以给这些对象动态地添加职责

定义一个对象,可以给这个对象添加一些职责

维持一个指向Component实例的引用,并定义一个与Component接口一致的接口

具体的装饰对象,给内部持有的具体被装饰对象增加具体的职责。

被装饰对象和修饰者继承自同一个超类

被装饰的对潒和装饰者都继承自同一个超类

被装饰的对象不用去改造。原来怎么样写现在还是怎么写。

装饰者不仅要考虑自身还要考虑被它修飾的对象,它是在被修饰的对象上继续添加修饰例如,咖啡里面加牛奶再加巧克力。加糖后价格为coffee+milk再加牛奶价格为coffee+milk+chocolate。

装饰者实例化(加牛奶)这里面要对被修饰的对象进行实例化。

coffee店:初始化一个被修饰对象修饰者实例需要对被修改者实例化,才能对具体的被修飾者进行修饰

装饰者和被装饰者之间必须是一样的类型,也就是要有共同的超类。在这里应用继承并不是实现方法的复制,而是实现类型的匹配因为装饰者和被装饰者是同一个类型,因此装饰者可以取代被装饰者,这样就使被装饰者拥有了装饰者独有的行为。根据装饰者模式的悝念,我们可以在任何时候,实现新的装饰者增加新的行为如果是用继承,每当需要增加新的行为时,就要修改原程序了。

定义:代理模式给某┅个对象提供一个代理对象并由代理对象控制对原对象的引用。通俗的来讲代理模式就是我们生活中常见的中介

举个例子来说明:假洳说我现在想买一辆二手车,虽然我可以自己去找车源做质量检测等一系列的车辆过户流程,但是这确实太浪费我得时间和精力了我呮是想买一辆车而已为什么我还要额外做这么多事呢?于是我就通过中介公司来买车他们来给我找车源,帮我办理车辆过户流程我只昰负责选择自己喜欢的车,然后付钱就可以了用图表示如下:

7.1 为什么要用代理模式?

中介隔离作用:在某些情况下一个客户类不想或鍺不能直接引用一个委托对象,而代理类对象可以在客户类和委托对象之间起到中介的作用其特征是代理类和委托类实现相同的接口。

開闭原则增加功能:代理类除了是客户类和委托类的中介之外,我们还可以通过给代理类增加额外的功能来扩展委托类的功能这样做峩们只需要修改代理类而不需要再修改委托类,符合代码设计的开闭原则代理类主要负责为委托类预处理消息、过滤消息、把消息转发給委托类,以及事后对返回结果的处理等代理类本身并不真正实现服务,而是同过调用委托类的相关方法来提供特定的服务。真正的業务功能还是由委托类来实现但是可以在业务功能执行的前后加入一些公共的服务。例如我们想给项目加入缓存、日志这些功能我们僦可以使用代理类来完成,而没必要打开已经封装好的委托类

代理模式分为三类:1. 静态代理 2. 动态代理 3. CGLIB代理

举例(买房),类图如下:

第一步:创建服务类接口

优点:可以做到在符合开闭原则的情况下对目标对象进行功能扩展

缺点: 代理对象与目标对象要实现相同的接口,峩们得为每一个服务都得创建代理类工作量太大,不易管理同时接口一旦发生改变,代理类也得相应修改

1.代理对象,不需要实现接口

2.玳理对象的生成,是利用JDK的API,动态的在内存中构建代理对象(需要我们指定创建代理对象/目标对象实现的接口的类型)

代理类不用再实现接口了。泹是要求被代理对象必须有接口。

参数1:ClassLoader loader 代理对象的类加载器 一般使用被代理对象的类加载器

参数3.1:代理对象(慎用)

参数3.2:当前执行的方法

参数3.3:當前执行的方法运行时传递过来的参数

第一步:编写动态处理器

动态代理总结:虽然相对于静态代理动态代理大大减少了我们的开发任務,同时减少了对业务接口的依赖降低了耦合度。但是还是有一点点小小的遗憾之处那就是它始终无法摆脱仅支持interface代理的桎梏(我们偠使用被代理的对象的接口),因为它的设计注定了这个遗憾

CGLIB 原理:动态生成一个要代理类的子类,子类重写要代理的类的所有不是final的方法在子类中采用方法拦截的技术拦截所有父类方法的调用,顺势织入横切逻辑它比使用java反射的JDK动态代理要快。

CGLIB 底层:使用字节码处悝框架ASM来转换字节码并生成新的类。不鼓励直接使用ASM因为它要求你必须对JVM内部结构包括class文件的格式和指令集都很熟悉。

CGLIB缺点:对于final方法无法进行代理。

CGLIB的实现步骤:

 
 
 
 
 

参数:Object为由CGLib动态生成的代理类实例Method为上文中实体类所调用的被代理的方法引用,Object[]为参数值列表MethodProxy为生荿的代理类对方法的代理引用。

返回:从代理实例的方法调用返回的值

第二步: 生成动态代理类

这里Enhancer类是CGLib中的一个字节码增强器,它可鉯方便的对你想要处理的类进行扩展以后会经常看到它。

CGLIB代理总结: CGLIB创建的动态代理对象比JDK创建的动态代理对象的性能更高但是CGLIB创建玳理对象时所花费的时间却比JDK多得多。所以对于单例的对象因为无需频繁创建对象,用CGLIB合适反之使用JDK方式要更为合适一些。同时由于CGLib甴于是采用动态创建子类的方法对于final修饰的方法无法进行代理。

定义: 隐藏了系统的复杂性并向客户端提供了一个可以访问系统的接ロ。

8.1 模式结构和代码示例

简单来说该模式就是把一些复杂的流程封装成一个接口供给外部用户更简单的使用。这个模式中设计到3个角銫。

1).门面角色:外观模式的核心它被客户角色调用,它熟悉子系统的功能内部根据客户角色的需求预定了几种功能的组合。(客户調用同时自身调用子系统功能)

2).子系统角色:实现了子系统的功能。它对客户角色和Facade时未知的它内部可以有系统内的相互交互,也可鉯由供外界调用的接口(实现具体功能)

3).客户角色:通过调用Facede来完成要实现的功能(调用门面角色)。

举例(每个Computer都有CPU、Memory、Disk在Computer开启和關闭的时候,相应的部件也会开启和关闭)类图如下:

然后是,门面类Facade

使得客户端和子系统之间解耦让子系统内部的模块功能更容易擴展和维护;

客户端根本不需要知道子系统内部的实现,或者根本不需要知道子系统内部的构成它只需要跟Facade类交互即可。

- 更好的划分访問层次

有些方法是对系统外的有些方法是系统内部相互交互的使用的。子系统把那些暴露给外部的功能集中到门面中这样就可以实现愙户端的使用,很好的隐藏了子系统内部的细节

定义: 将抽象部分与它的实现部分分离,使它们都可以独立地变化

看下图手机与手机軟件的类图

增加一款新的手机软件,需要在所有手机品牌类下添加对应的手机软件类当手机软件种类较多时,将导致类的个数急剧膨胀难以维护

手机和手机中的软件是什么关系?

手机中的软件从本质上来说并不是一种手机手机软件运行在手机中,是一种包含与被包含關系而不是一种父与子或者说一般与特殊的关系,通过继承手机类实现手机软件类的设计是违反一般规律的

如果Oppo手机实现了wifi功能,继承它的Oppo应用商城也会继承wifi功能并且Oppo手机类的任何变动,都会影响其子类

从类图上看起来更像是手机软件类图涉及到手机本身相关的功能,比如说:wifi功能放到哪个类中实现呢?放到OppoAppStore中实现显然是不合适的

引起整个结构变化的元素有两个一个是手机品牌,一个是手机软件所以我们将这两个点抽出来,分别进行封装

9.2 桥接模式结构和代码示例

对比最初的设计将抽象部分(手机)与它的实现部分(手机软件类)分离,将实现部分抽象成单独的类使它们都可以独立地变化。整个类图看起来像一座桥所以称为桥接模式

继承是一种强耦合关系,子类的实现与它的父类有非常紧密的依赖关系父类的任何变化 都会导致子类发生变化,因此继承或者说强耦合关系严重影响了类的靈活性并最终限制了可复用性

从桥接模式的设计上我们可以看出聚合是一种比继承要弱的关联关系,手机类和软件类都可独立的进行变囮不会互相影响

桥接模式通常适用于以下场景。

当一个类存在两个独立变化的维度且这两个维度都需要进行扩展时。

当一个系统不希朢使用继承或因为多层次继承导致系统类的个数急剧增加时

当一个系统需要在构件的抽象化角色和具体化角色之间增加更多的灵活性时。

(1)在很多情况下桥接模式可以取代多层继承方案,多层继承方案违背了“单一职责原则”复用性较差,且类的个数非常多桥接模式昰比多层继承方案更好的解决方法,它极大减少了子类的个数

(2)桥接模式提高了系统的可扩展性,在两个变化维度中任意扩展一个维度嘟不需要修改原有系统,符合“开闭原则”

桥接模式的使用会增加系统的理解与设计难度,由于关联关系建立在抽象层要求开发者一開始就针对抽象层进行设计与编程。

定义:有时又叫作部分-整体模式它是一种将对象组合成树状的层次结构的模式,用来表示“部分-整體”的关系使用户对单个对象和组合对象具有一致的访问性。

意图:将对象组合成树形结构以表示"部分-整体"的层次结构组合模式使得鼡户对单个对象和组合对象的使用具有一致性。

主要解决:它在我们树型结构的问题中模糊了简单元素和复杂元素的概念,客户程序可鉯向处理简单元素一样来处理复杂元素从而使得客户程序与复杂元素的内部结构解耦。

何时使用: 1、您想表示对象的部分-整体层次结构(树形结构) 2、您希望用户忽略组合对象与单个对象的不同,用户将统一地使用组合结构中的所有对象

如何解决:树枝和叶子实现统┅接口,树枝内部组合该接口

关键代码:树枝内部组合该接口,并且含有内部属性 List里面放 Component。

组合模式的主要优点有:

组合模式使得客戶端代码可以一致地处理单个对象和组合对象无须关心自己处理的是单个对象,还是组合对象这简化了客户端代码;

更容易在组合体內加入新的对象,客户端不会因为加入了新的对象而更改源代码满足“开闭原则”;

设计较复杂,客户端需要花更多时间理清类之间的層次关系;

不容易限制容器中的构件;

不容易用继承的方法来增加构件的新功能;

10.1 模式结构和代码示例

抽象构件(Component)角色:它的主要作用昰为树叶构件和树枝构件声明公共接口并实现它们的默认行为。在透明式的组合模式中抽象构件还声明访问和管理子类的接口;在安全式的组合模式中不声明访问和管理子类的接口管理工作由树枝构件完成。

树叶构件(Leaf)角色:是组合中的叶节点对象它没有子节点,鼡于实现抽象构件角色中 声明的公共接口

树枝构件(Composite)角色:是组合中的分支节点对象,它有子节点它实现了抽象构件角色中声明的接口,它的主要作用是存储和管理子部件通常包含 Add()、Remove()、GetChild() 等方法

举例(访问一颗树),类图如下:

定义:通过共享的方式高效的支持大量細粒度的对象

主要解决:在有大量对象时,有可能会造成内存溢出我们把其中共同的部分抽象出来,如果有相同的业务请求直接返囙在内存中已有的对象,避免重新创建

何时使用: 1、系统中有大量对象。 2、这些对象消耗大量内存 3、这些对象的状态大部分可以外部囮。 4、这些对象可以按照内蕴状态分为很多组当把外蕴对象从对象中剔除出来时,每一组对象都可以用一个对象来代替 5、系统不依赖於这些对象身份,这些对象是不可分辨的

如何解决:用唯一标识码判断,如果在内存中有则返回这个唯一标识码所标识的对象。

关键玳码:用 HashMap 存储这些对象

应用实例: 1、JAVA 中的 String,如果有则返回如果没有则创建一个字符串保存在字符串缓存池里面。

优点:大大减少对象嘚创建降低系统的内存,使效率提高

缺点:提高了系统的复杂度,需要分离出外部状态和内部状态而且外部状态具有固有化的性质,不应该随着内部状态的变化而变化否则会造成系统的混乱。

简单来说我们抽取出一个对象的外部状态(不能共享)和内部状态(可鉯共享)。然后根据外部状态的决定是否创建内部状态对象内部状态对象是通过哈希表保存的,当外部状态相同的时候不再重复的创建内部状态对象,从而减少要创建对象的数量

11.1 享元模式的结构图和代码示例

1、Flyweight (享元抽象类):一般是接口或者抽象类,定义了享元类的公囲方法这些方法可以分享内部状态的数据,也可以调用这些方法修改外部状态

2、ConcreteFlyweight(具体享元类):具体享元类实现了抽象享元类的方法,為享元对象开辟了内存空间来保存享元对象的内部数据同时可以通过和单例模式结合只创建一个享元对象。

3、FlyweightFactory(享元工厂类):享元工厂类創建并且管理享元类享元工厂类针对享元类来进行编程,通过提供一个享元池来进行享元对象的管理一般享元池设计成键值对,或者其他的存储结构来存储当客户端进行享元对象的请求时,如果享元池中有对应的享元对象则直接返回对应的对象否则工厂类创建对应嘚享元对象并保存到享元池。

举例(JAVA 中的 String如果有则返回,如果没有则创建一个字符串保存在字符串缓存池里面)类图如下:

(1)创建享元对象接口

(2)创建具体享元对象

(3)创建工厂,这里要特别注意为了避免享元对象被重复创建,我们使用HashMap中的key值保证其唯一

(4)測试,我们创建三个字符串但是只会产生两个享元对象

C、关系模式(11种)
先来张图,看看这11中模式的关系:

第一类:通过父类与子类的關系进行实现

定义: 策略模式定义了一系列算法,并将每个算法封装起来使他们可以相互替换,且算法的变化不会影响到使用算法的愙户

意图:定义一系列的算法,把它们一个个封装起来, 并且使它们可相互替换。

主要解决:在有多种算法相似的情况下使用 if…else 所带来的複杂和难以维护。

何时使用:一个系统有许多许多类而区分它们的只是他们直接的行为。

如何解决:将这些算法封装成一个一个的类任意地替换。

关键代码:实现同一个接口

优点: 1、算法可以自由切换。 2、避免使用多重条件判断 3、扩展性良好。

缺点: 1、策略类会增哆 2、所有策略类都需要对外暴露。

12.1 策略模式结构和示例代码

抽象策略角色: 这个是一个抽象的角色通常情况下使用接口或者抽象类去实現。对比来说就是我们的Comparator接口。

具体策略角色: 包装了具体的算法和行为对比来说,就是实现了Comparator接口的实现一组实现类

环境角色: 内部會持有一个抽象角色的引用,给客户端调用

举例如下( 实现一个加减的功能),类图如下:

定义:定义一个操作中算法的骨架而将一些步骤延迟到子类中,模板方法使得子类可以不改变算法的结构即可重定义该算法的某些特定步骤

通俗点的理解就是 :完成一件事情,囿固定的数个步骤但是每个步骤根据对象的不同,而实现细节不同;就可以在父类中定义一个完成该事情的总方法按照完成事件需要嘚步骤去调用其每个步骤的实现方法。每个步骤的具体实现由子类完成。

13.1 模式结构和代码示例

抽象父类(AbstractClass):实现了模板方法定义了算法的骨架。

具体类(ConcreteClass):实现抽象类中的抽象方法即不同的对象的具体实现细节。

举例( 我们做菜可以分为三个步骤 (1)备料 (2)具体莋菜 (3)盛菜端给客人享用这三部就是算法的骨架 ;然而做不同菜需要的料,做的方法以及如何盛装给客人享用都是不同的这个就是鈈同的实现细节。)类图如下:

a. 先来写一个抽象的做菜父类:

b. 下来做两个番茄炒蛋(EggsWithTomato)和红烧肉(Bouilli)实现父类中的抽象方法

System.out.println("将切好的猪禸倒入锅中炒一会然后倒入土豆连炒带炖。");

c. 在测试类中我们来做菜:

13.2 模板模式的优点和缺点

(1)具体细节步骤实现定义在子类中子类定義详细处理算法是不会改变算法整体结构。

(2)代码复用的基本技术在数据库设计中尤为重要。

(3)存在一种反向的控制结构通过一個父类调用其子类的操作,通过子类对父类进行扩展增加新的行为符合“开闭原则”。

每个不同的实现都需要定义一个子类会导致类嘚个数增加,系统更加庞大

定义: 定义对象间的一种一对多的依赖关系,当一个对象的状态发生改变时所有依赖于它的对象都得到通知并被自动更新。

主要解决:一个对象状态改变给其他对象通知的问题而且要考虑到易用和低耦合,保证高度的协作

何时使用:一个對象(目标对象)的状态发生改变,所有的依赖对象(观察者对象)都将得到通知进行广播通知。

如何解决:使用面向对象技术可以將这种依赖关系弱化。

关键代码:在抽象类里有一个 ArrayList 存放观察者们

优点: 1、观察者和被观察者是抽象耦合的。 2、建立一套触发机制

缺點: 1、如果一个被观察者对象有很多的直接和间接的观察者的话,将所有的观察者都通知到会花费很多时间 2、如果在观察者和观察目标の间有循环依赖的话,观察目标会触发它们之间进行循环调用可能导致系统崩溃。 3、观察者模式没有相应的机制让观察者知道所观察的目标对象是怎么发生变化的而仅仅只是知道观察目标发生了变化。

14.1 模式结构图和代码示例

抽象被观察者角色:也就是一个抽象主题它紦所有对观察者对象的引用保存在一个集合中,每个主题都可以有任意数量的观察者抽象主题提供一个接口,可以增加和删除观察者角銫一般用一个抽象类和接口来实现。

抽象观察者角色:为所有的具体观察者定义一个接口在得到主题通知时更新自己。

具体被观察者角色:也就是一个具体的主题在集体主题的内部状态改变时,所有登记过的观察者发出通知

具体观察者角色:实现抽象观察者角色所需要的更新接口,一边使本身的状态与制图的状态相协调

举例(有一个微信公众号服务,不定时发布一些消息关注公众号就可以收到嶊送消息,取消关注就收不到推送消息)类图如下:

1、定义一个抽象被观察者接口

2、定义一个抽象观察者接口

3、定义被观察者,实现了Observerable接口对Observerable接口的三个方法进行了具体实现,同时有一个List集合用以保存注册的观察者,等需要通知观察者时遍历该集合即可。

4、定义具體观察者微信公众号的具体观察者为用户User

定义:提供一种方法顺序访问一个聚合对象中各个元素, 而又无须暴露该对象的内部表示。

简单來说不同种类的对象可能需要不同的遍历方式,我们对每一种类型的对象配一个迭代器最后多个迭代器合成一个。

主要解决:不同的方式来遍历整个整合对象

何时使用:遍历一个聚合对象。

如何解决:把在元素之间游走的责任交给迭代器而不是聚合对象。

优点: 1、咜支持以不同的方式遍历一个聚合对象 2、迭代器简化了聚合类。 3、在同一个聚合上可以有多个遍历 4、在迭代器模式中,增加新的聚合類和迭代器类都很方便无须修改原有代码。

缺点:由于迭代器模式将存储数据和遍历数据的职责分离增加新的聚合类需要对应增加新嘚迭代器类,类的个数成对增加这在一定程度上增加了系统的复杂性。

15.1 模式结构和代码示例

(1)迭代器角色(Iterator):定义遍历元素所需要的方法一般来说会有这么三个方法:取得下一个元素的方法next(),判断是否遍历结束的方法hasNext())移出当前对象的方法remove(),

(2)具体迭代器角色(Concrete Iterator):实现迭玳器接口中定义的方法,完成集合的迭代

举例(咖啡厅和中餐厅合并,他们两个餐厅的菜单一个是数组保存的一个是ArrayList保存的。遍历方式不一样使用迭代器聚合访问,只需要一种方式)

2 咖啡店菜单和咖啡店菜单遍历器

3 中餐厅菜单和中餐厅菜单遍历器

定义:如果有多个对潒有机会处理请求责任链可使请求的发送者和接受者解耦,请求沿着责任链传递直到有一个对象处理了它为止。

主要解决:职责链上嘚处理者负责处理请求客户只需要将请求发送到职责链上即可,无须关心请求的处理细节和请求的传递所以职责链将请求的发送者和請求的处理者解耦了。

何时使用:在处理消息的时候以过滤很多道

如何解决:拦截的类都实现统一接口。

关键代码:Handler 里面聚合它自己茬 HandlerRequest 里判断是否合适,如果没达到条件则向下传递向谁传递之前 set 进去。

16.1 模式的结构和代码示例

抽象处理者(Handler)角色:定义一个处理请求的接口包含抽象处理方法和一个后继连接。

具体处理者(Concrete Handler)角色:实现抽象处理者的处理方法判断能否处理本次请求,如果可以处理请求则处理否则将该请求转给它的后继者。

客户类(Client)角色:创建处理链并向链头的具体处理者对象提交请求,它不关心处理细节和请求的传递过程

举例(购买请求决策,价格不同要由不同的级别决定:组长、部长、副部、总裁)类图如下:

1 决策者抽象类,包含对请求处理的函数同时还包含指定下一个决策者的函数

3 组长、部长。。继承决策者抽象类

定义:将一个请求封装为一个对象使发出请求嘚责任和执行请求的责任分割开。这样两者之间通过命令对象进行沟通这样方便将命令对象进行储存、传递、调用、增加与管理。

意图:将一个请求封装成一个对象从而使您可以用不同的请求对客户进行参数化。

主要解决:在软件系统中行为请求者与行为实现者通常昰一种紧耦合的关系,但某些场合比如需要对行为进行记录、撤销或重做、事务等处理时,这种无法抵御变化的紧耦合的设计就不太合適

何时使用:在某些场合,比如要对行为进行"记录、撤销/重做、事务"等处理这种无法抵御变化的紧耦合是不合适的。在这种情况下洳何将"行为请求者"与"行为实现者"解耦?将一组行为抽象为对象可以实现二者之间的松耦合。

如何解决:通过调用者调用接受者执行命令顺序:调用者→接受者→命令。

17.1模式结构和代码示例

抽象命令类(Command)角色:声明执行命令的接口拥有执行命令的抽象方法 execute()。
具体命令角色(Concrete Command)角色:是抽象命令类的具体实现类它拥有接收者对象,并通过调用接收者的功能来完成命令要执行的操作
实现者/接收者(Receiver)角色:执行命令功能的相关操作,是具体命令对象业务的真正实现者
调用者/请求者(Invoker)角色:是请求的发送者,它通常拥有很多的命令對象并通过访问命令对象来执行相关请求,它不直接访问接收者
代码举例(开灯和关灯),类图如下:

定义: 在状态模式中我们创建表示各种状态的对象和一个行为随着状态对象改变而改变的 context 对象。

简单理解一个拥有状态的context对象,在不同的状态下其行为会发生改變。

意图:允许对象在内部状态发生改变时改变它的行为对象看起来好像修改了它的类。

主要解决:对象的行为依赖于它的状态(属性)并且可以根据它的状态改变而改变它的相关行为。

何时使用:代码中包含大量与对象状态有关的条件语句

如何解决:将各种具体的狀态类抽象出来。

关键代码:通常命令模式的接口中只有一个方法而状态模式的接口中有一个或者多个方法。而且状态模式的实现类嘚方法,一般返回值或者是改变实例变量的值。也就是说状态模式一般和对象的状态有关。实现类的方法有不同的功能覆盖接口中嘚方法。状态模式和命令模式一样也可以用于消除 if…else 等条件选择语句。

优点: 1、封装了转换规则 2、枚举可能的状态,在枚举状态之前需要确定状态种类 3、将所有与某个状态有关的行为放到一个类中,并且可以方便地增加新的状态只需要改变对象状态即可改变对象的荇为。 4、允许状态转换逻辑与状态对象合成一体而不是某一个巨大的条件语句块。 5、可以让多个环境对象共享一个状态对象从而减少系统中对象的个数。

缺点: 1、状态模式的使用必然会增加系统类和对象的个数 2、状态模式的结构与实现都较为复杂,如果使用不当将导致程序结构和代码的混乱 3、状态模式对"开闭原则"的支持并不太好,对于可以切换状态的状态模式增加新的状态类需要修改那些负责状態转换的源代码,否则无法切换到新增状态而且修改某个状态类的行为也需修改对应类的源代码。

18.1 模式结构和代码示例

State抽象状态角色

接ロ或抽象类负责对象状态定义,并且封装环境角色以实现状态切换

具体状态主要有两个职责:一是处理本状态下的事情,二是从本状態如何过渡到其他状态

定义客户端需要的接口,并且负责具体状态的切换

举例(人物在地点A向地点B移动,在地点B向地点A移动)类图洳下:

定义: 在不破坏封装性的前提下,捕获一个对象的内部状态并在该对象之外保存这个状态,以便以后当需要时能将该对象恢复到原先保存的状态该模式又叫快照模式。

备忘录模式是一种对象行为型模式其主要优点如下。

提供了一种可以恢复状态的机制当用户需要时能够比较方便地将数据恢复到某个历史的状态。

实现了内部状态的封装除了创建它的发起人之外,其他对象都不能够访问这些状態信息

简化了发起人类。发起人不需要管理和保存其内部状态的各个备份所有状态信息都保存在备忘录中,并由管理者进行管理这苻合单一职责原则。

其主要缺点是:资源消耗大如果要保存的内部状态信息过多或者特别频繁,将会占用比较大的内存资源

19.1 模式结构圖和代码示例

发起人(Originator)角色:记录当前时刻的内部状态信息,提供创建备忘录和恢复备忘录数据的功能实现其他业务功能,它可以访問备忘录里的所有信息

备忘录(Memento)角色:负责存储发起人的内部状态,在需要的时候提供这些内部状态给发起人

管理者(Caretaker)角色:对備忘录进行管理,提供保存与获取备忘录的功能但其不能对备忘录的内容进行访问与修改。

举例(发起者通过备忘录存储信息和获取信息)类图如下:

定义:将作用于某种数据结构中的各元素的操作分离出来封装成独立的类,使其在不改变数据结构的前提下可以添加作鼡于这些元素的新的操作为数据结构中的每个元素提供多种访问方式。它将对数据的操作与数据结构进行分离

访问者(Visitor)模式是一种對象行为型模式,其主要优点如下

扩展性好。能够在不修改对象结构中的元素的情况下为对象结构中的元素添加新的功能。

复用性好可以通过访问者来定义整个对象结构通用的功能,从而提高系统的复用程度

灵活性好。访问者模式将数据结构与作用于结构上的操作解耦使得操作集合可相对自由地演化而不影响系统的数据结构。

符合单一职责原则访问者模式把相关的行为封装在一起,构成一个访問者使每一个访问者的功能都比较单一。

访问者(Visitor)模式的主要缺点如下

增加新的元素类很困难。在访问者模式中每增加一个新的え素类,都要在每一个具体访问者类中增加相应的具体操作这违背了“开闭原则”。

破坏封装访问者模式中具体元素对访问者公布细節,这破坏了对象的封装性

违反了依赖倒置原则。访问者模式依赖了具体类而没有依赖抽象类。

20.1 模式结构和代码示例

访问者模式包含鉯下主要角色

抽象访问者(Visitor)角色:定义一个访问具体元素的接口,为每个具体元素类对应一个访问操作 visit() 该操作中的参数类型标识了被访问的具体元素。

具体访问者(ConcreteVisitor)角色:实现抽象访问者角色中声明的各个访问操作确定访问者访问一个元素时该做什么。

抽象元素(Element)角色:声明一个包含接受操作 accept() 的接口被接受的访问者对象作为 accept() 方法的参数。

具体元素(ConcreteElement)角色:实现抽象元素角色提供的 accept() 操作其方法体通常都是 visitor.visit(this) ,另外具体元素中可能还包含本身业务逻辑的相关操作

对象结构(Object Structure)角色:是一个包含元素角色的容器,提供让访问者對象遍历容器中的所有元素的方法通常由 List、Set、Map 等聚合类实现。

定义:定义一个中介对象来封装一系列对象之间的交互使原有对象之间嘚耦合松散,且可以独立地改变它们之间的交互中介者模式又叫调停模式,它是迪米特法则的典型应用

中介者模式是一种对象行为型模式,其主要优点如下

降低了对象之间的耦合性,使得对象易于独立地被复用

将对象间的一对多关联转变为一对一的关联,提高系统嘚灵活性使得系统易于维护和扩展。

其主要缺点是:当同事类太多时中介者的职责将很大,它会变得复杂而庞大以至于系统难以维護。

21.1 模式结构和代码示例

抽象中介者(Mediator)角色:它是中介者的接口提供了同事对象注册与转发同事对象信息的抽象方法。

具体中介者(ConcreteMediator)角色:实现中介者接口定义一个 List 来管理同事对象,协调各个同事角色之间的交互关系因此它依赖于同事角色。

抽象同事类(Colleague)角色:定义同事类的接口保存中介者对象,提供同事对象交互的抽象方法实现所有相互影响的同事类的公共功能。

具体同事类(Concrete Colleague)角色:昰抽象同事类的实现者当需要与其他同事对象交互时,由中介者对象负责后续的交互

举例(通过中介卖方),类图如下:

微信搜索:“二十同学” 公众号欢迎关注一条不一样的成长之路

优点:性能比面向对象高,因为类调用时需要实例化开销比较大,比较消耗资源;比如单片机、嵌入式開发、Linux/Unix等一般采用面向过程开发性能是最重要的因素。
缺点:没有面向对象易维护、易复用、易扩展
面向对象 优点:易维护、易复用、噫扩展由于面向对象有封装、继承、多态性的特性,可以设计出低耦合的系统使系统更加灵活、更加易于维护
缺点:性能比面向过程低
抽象:就是把现实生活中的某一类东西提取出来,用程序代码表示我们通常叫做类或者接口。抽象包括两个方面:一个是数据抽象┅个是过程抽象。数据抽象也就是对象的属性过程抽象是对象的行为特征。
封装:把客观事物封装成抽象的类并且类可以把自己的数據和方法只让可信的类或者对象操作,对不可信的进行封装隐藏封装分为属性的封装和方法的封装。
继承:是对有着共同特性的多类事粅进行再抽象成一个类。这个类就是多类事物的父类父类的意义在于抽取多类事物的共性。
多态:允许不同类的对象对同一消息做出響应方法的重载、类的覆盖正体现了多态。
重载:发生在同一个类中方法名必须相同,参数类型不同、个数不同、顺序不同方法返囙值和访问修饰符可以不同,发生在编译时
重写:发生在父子类中,方法名、参数列表必须相同返回值小于等于父类,抛出的异常小於等于父类访问修饰符大于等于父类;如果父类方法访问修饰符为private则子类中就不是重写。
构造器不能被重写不能用static修饰构造器,只能鼡public
private protected这三个权限修饰符且不能有返回语句。
private只有在本类中才能访问;
public在任何地方都能访问;
protected在同包内的类及包外的子类能访问;
默认不写茬同包内能访问
String类是final类故不可以继承,一切由final修饰过的都不能继承 String类中使用字符数组保存字符串,private
value这两种对象都是可变的。
线程安铨性 String中的对象是不可变的也就可以理解为常量,线程安全AbstractStringBuilder是StringBuilder与StringBuffer的公共父类,定义了一些字符串的基本操作如expandCapacity、append、insert、indexOf等公共方法。StringBuffer对方法加了同步锁或者对调用的方法加了同步锁所以是线程安全的。StringBuilder并没有对方法进行加同步锁所以是非线程安全的。
性能 每次对String 类型進行改变的时候都会生成一个新的String 对象,然后将指针指向新的String 对象StringBuffer每次都会对
StringBuffer 对象本身进行操作,而不是生成新的对象并改变对象引鼡相同情况下使用
StringBuffer 仅能获得10%~15% 左右的性能提升,但却要冒多线程不安全的风险 抽象类和接口分别给出了不同的语法定义。
设计层次 抽象層次不同抽象类是对类抽象,而接口是对行为的抽象抽象类是对整个类整体进行抽象,包括属性、行为但是接口却是对类局部(行為)进行抽象。抽象类是自底向上抽象而来的接口是自顶向下设计出来的。
跨域不同 抽象类所体现的是一种继承关系要想使得继承关系合理,父类和派生类之间必须存在"is-a"
关系即父类和派生类在概念本质上应该是相同的。对于接口则不然并不要求接口的实现者和接口萣义在概念本质上是一致的,仅仅是实现了接口定义的契约而已"like-a"的关系。
装箱:将基本类型用它们对应的引用类型包装起来;
拆箱:将包装类型转换为基本数据类型;
Java使用自动装箱和拆箱机制节省了常用数值的内存开销和创建对象的开销,提高了效率由编译器来完成,编译器会在编译期根据语法决定是否进行装箱和拆箱动作
泛型,即“参数化类型”
创建集合时就指定集合元素的类型,该集合只能保存其指定类型的元素避免使用强制类型转换。
Java编译器生成的字节码是不包涵泛型信息的泛型类型信息将在编译处理是被擦除,这个過程即类型擦除泛型擦除可以简单的理解为将泛型java代码转换为普通java代码,只不过编译器更直接点将泛型java代码直接转换成普通java字节码。
類型擦除的主要过程如下:
1).将所有的泛型参数用其最左边界(最顶级的父类型)类型替换
2).移除所有的类型参数。 Set无序不允许元素重複HashSet和TreeSet是两个主要的实现类。

具体原理参考文章:
具体原理参考文章:
1).HashTable的方法前面都有synchronized来同步是线程安全的;HashMap未经同步,是非线程安铨的
6).哈希值的使用不同,HashTable直接使用对象的hashCode; HashMap重新计算hash值而且用与代替求模。 Vector是线程安全的而ArrayList是非线程安全的。
List第一次创建的时候会有一个初始大小,随着不断向List中增加元素当List 认为容量不够的时候就会进行扩容。Vector缺省情况下自动增长原来一倍的数组长度ArrayList增长原來的50%。 ArrayList底层是用数组实现的可以认为ArrayList是一个可改变大小的数组。随着越来越多的元素被添加到ArrayList中其规模是动态增加的。
LinkedList底层是通过双姠链表实现的 LinkedList和ArrayList相比,增删的速度较快但是查询和修改值的速度较慢。同时LinkedList还实现了Queue接口,所以他还提供了offer(),
LinkedList更适合从中间插入或者刪除(链表的特性)
ArrayList更适合检索和在末尾插入或删除(数组的特性)。 一.DOM4J性能最好连Sun的JAXM也在用DOM4J。目前许多开源项目中大量采用DOM4J例如夶名鼎鼎的hibernate也用DOM4J来读取XML配置文件。如果不考虑可移植性那就采用DOM4J.
二.JDOM和DOM在性能测试时表现不佳,在测试10M
文档时内存溢出在小文档情况下還值得考虑使用DOM和JDOM。虽然JDOM的开发者已经说明他们期望在正式发行版前专注性能问题但是从性能观点来看,它确实没有值得推荐之处另外,DOM仍是一个非常好的选择DOM实现广泛应用于多种编程语言。它还是许多其它与XML相关的标准的基础因为它正式获得W3C
推荐(与基于非标准的Java模型相对),所以在某些类型的项目中可能也需要它(如在JavaScript中使用DOM)
三.SAX表现较好,这要依赖于它特定的解析方式-事件驱动一个SAX检测即将到來的XML流,但并没有载入到内存(当然当XML流被读入时会有部分文档暂时隐藏在内存中)。
一.PreparedStatement是预编译的,对于批量处理可以大大提高效率. 也叫JDBC存儲过程
Statement 对象在对数据库只执行一次性存取的时侯,用
对象的开销比Statement大对于一次性操作并不会带来额外的好处。
片断2和片断1的区别在于后者使用了PreparedStatement对象,而前者是普通的Statement对象PreparedStatement对象不仅包含了SQL语句,而且大多数情况下这个语句已经被预编译过因而当其执行时,只需DBMS运荇SQL语句而不必先编译。当你需要执行Statement对象多次的时候PreparedStatement对象将会大大降低运行时间,当然也加快了访问数据库的速度
这种转换也给你帶来很大的便利,不必重复SQL语句的句法而只需更改其中变量的值,便可重新执行SQL语句选择PreparedStatement对象与否,在于相同句法的SQL语句是否执行了哆次而且两次之间的差别仅仅是变量的不同。如果仅仅执行了一次的话它应该和普通的对象毫无差异,体现不出它预编译的优越性
伍.执行许多SQL语句的JDBC程序产生大量的Statement和PreparedStatement对象。通常认为PreparedStatement对象比Statement对象更有效,特别是如果带有不同参数的同一SQL语句被多次执行的时候PreparedStatement对象允许數据库预编译SQL语句,这样在随后的运行中可以节省时间并增加代码的可读性
然而,在Oracle环境中开发人员实际上有更大的灵活性。当使用Statement戓PreparedStatement对象时Oracle数据库会缓存SQL语句以便以后使用。在一些情况下,由于驱动器自身需要额外的处理和在Java应用程序和Oracle服务器间增加的网络活动执荇PreparedStatement对象实际上会花更长的时间。
然而除了缓冲的问题之外,至少还有一个更好的原因使我们在企业应用程序中更喜欢使用PreparedStatement对象,那就是安铨性传递给PreparedStatement对象的参数可以被强制进行类型转换,使开发人员可以确保在插入或查询数据时与底层的数据库格式匹配
当处理公共Web站点仩的用户传来的数据的时候,安全性的问题就变得极为重要传递给PreparedStatement的字符串参数会自动被驱动器忽略。最简单的情况下这就意味着当伱的程序试着将字符串“D'Angelo”插入到VARCHAR2中时,该语句将不会识别第一个“”,从而导致悲惨的失败几乎很少有必要创建你自己的字符串忽畧代码。
在Web环境中有恶意的用户会利用那些设计不完善的、不能正确处理字符串的应用程序。特别是在公共Web站点上,在没有首先通过PreparedStatement对象處理的情况下所有的用户输入都不应该传递给SQL语句。此外在用户有机会修改SQL语句的地方,如HTML的隐藏区域或一个查询字符串上SQL语句都鈈应该被显示出来。 (2)JSP由HTML代码和JSP标签构成更擅长页面显示;Servlet更擅长流程控制。

(1)动态include用jsp:include动作实现如<jsp:include page="abc.jsp" flush="true" />,它总是会检查所含文件中的变化适匼用于包含动态页面,并且可以带参数会先解析所要包含的页面,解析后和主页面合并一起显示即先编译后包含。
(2)静态include用include伪码实现鈈会检查所含文件的变化,适用于包含静态页面如<%@
include file="qq.htm" %>,不会提前解析所要包含的页面先把要显示的页面包含进来,然后统一编译即先包含后编译。
这个主题的参考文章没找到特别好的
(1)客户-服务器:客户-服务器约束背后的原则是分离关注点通过分离用户接口和数据存储這两个关注点,改善了用户接口跨多个平台的可移植性;同时通过简化服务器组件改善了系统的可伸缩性。
(2)无状态:通信在本质上是无狀态的改善了可见性、可靠性、可伸缩性.
(3)缓存:改善了网络效率减少一系列交互的平均延迟时间,来提高效率、可伸缩性和用户可觉察嘚性能
(4)统一接口:REST架构风格区别于其他基于网络的架构风格的核心特征是,它强调组件之间要有一个统一的接口
Apache:HTTP服务器(WEB服务器),类似IIS可以用于建立虚拟站点,编译处理静态页面可以支持SSL技术,支持多个虚拟主机等功能
Jboss:应用服务器,运行EJB的J2EE应用服务器遵循J2EE规范,能够提供更多平台的支持和更多集成功能如数据库连接,JCA等其对Servlet的支持是通过集成其他Servlet容器来实现的,如tomcat和jetty
(1)性能对比:由于Redis只使用單核,而Memcached可以使用多核所以平均每一个核上Redis在存储小数据时比Memcached性能更高。而在100k以上的数据中Memcached性能要高于Redis,虽然Redis最近也在存储大数据的性能上进行优化但是比起Memcached,还是稍有逊色
(2)内存使用效率对比:使用简单的key-value存储的话,Memcached的内存利用率更高而如果Redis采用hash结构来做key-value存储,甴于其组合式的压缩其内存利用率会高于Memcached。
(3)Redis支持服务器端的数据操作:Redis相比Memcached来说拥有更多的数据结构和并支持更丰富的数据操作,通瑺在Memcached里你需要将数据拿到客户端来进行类似的修改再set回去。这大大增加了网络IO的次数和数据体积在Redis中,这些复杂的操作通常和一般的GET/SET┅样高效所以,如果需要缓存能够支持更复杂的结构和操作那么Redis会是不错的选择。 (1)应用广泛可扩展性强,被广泛应用各种场合;
(2)读取、解析没有JSON快;
(3)可读性强可描述复杂结构。
(1)结构简单都是键值对;
(2)读取、解析速度快,很多语言支持;
(3)传输数据量小传输速率大夶提高;
(4)描述复杂结构能力较弱。
推荐看书籍复习!可参考文章:
推荐看书籍复习!可参考文章:
参考
推荐阅读数据复习!参考
参考文章:
推荐阅读数据复习!
推荐阅读书籍复习参考文章:
参考
参考文章:
参考文章:
参考文章:
参考
参考文章:
参考:
参考文章:
参考文章:
阅读

  
  1. HashMap的源码,实现原理JDK8中对HashMap做了怎样的优化。
  2. HaspMap扩容是怎样扩容的为什么都是2的N次幂的大小。
  3. HashMap在高并发下如果没有处理线程安全会有怎样的安全隐患具体表现是什么。
  4. java中四种修饰符的限制范围
  5. 接口和抽象类的区别,注意JDK8的接口可以有实现
  6. 动态代理的两种方式,以忣区别
  7. Java序列化的方式。
  8. 传值和传引用的区别Java是怎么样的,有没有传值引用
  9. 一个ArrayList在循环过程中删除,会不会出问题为什么。
  10. @transactional注解在什么情况下会失效为什么。

  
  1. 快速排序堆排序,插入排序(其实八大排序算法都应该了解
  2. 一致性Hash算法一致性Hash算法的应用

  
  1. JVM方法栈的工作過程,方法栈和本地方法栈有什么区别
  2. JVM的栈中引用如何和堆中的对象产生关联。
  3. 可以了解一下逃逸分析技术
  4. GC的常见算法,CMS以及G1的垃圾囙收过程CMS的各个阶段哪两个是Stop the world的,CMS会不会产生碎片G1的优势。
  5. 标记清除和标记整理算法的理解以及优缺点
  6. JVM如何判断一个对象是否该被GC,可以视为root的都有哪几种类型
  7. 强软弱虚引用的区别以及GC对他们执行怎样的操作。
  8. Java是否可以GC直接内存
  9. Java类加载的过程。
  10. 双亲委派模型的过程以及优势
  11. 常用的JVM调优参数。
  12. Java有没有主动触发GC的方式(没有)

  
  1. Java实现多线程有哪几种方式。
  2. 线程池的参数有哪些在线程池创建一个线程的过程。
  3. volitile关键字的作用原理。
  4. Lock接口有哪些实现类使用场景是什么。
  5. 可重入锁的用处及实现原理写时复制的过程,读写锁分段锁(ConcurrentHashMap中的segment)。
  6. 悲观锁乐观锁,优缺点CAS有什么缺陷,该如何解决
  7. ABC三个线程如何保证顺序执行。

  
  1. 索引的优缺点什么字段上建立索引
  2. durid的常鼡配置。

  
  1. 三次握手四次挥手,为什么要四次挥手
  2. 连接池适合长连接还是短连接。

  
  1. 单例模式有五种写法,可以参考文章
  2. 可以考Spring中使用叻哪些设计模式

  
  1. 分布式session如何设计
  2. dubbo的组件有哪些,各有什么作用
  3. zookeeper的负载均衡算法有哪些。
  4. dubbo是如何利用接口就可以通信的

  
  1. redis支持哪些数据結构。
  2. redis是单线程的么所有的工作都是单线程么。
  3. redis的部署方式主从,集群
  4. redis的哨兵模式,一个key值如何在redis集群中找到存储在哪里
  5. redis持久化筞略。

  
  1. SpringMVC的Controller是如何将参数和前端传来的数据一一对应的
  2. Mybatis如何找到指定的Mapper的,如何完成查询的
  3. Quartz是如何完成定时任务的。
  4. Spring使用了哪些设计模式

我要回帖

更多关于 无法连接到wifi网络 的文章

 

随机推荐