4.结构型模式
4.1 适配器模式 Adapter Pattern
适配器模式充当两个不兼容接口之间的桥梁。 这种类型的设计模式属于结构模式，因为该模式结合了两个独立接口的功能。
**意图：**将一个类的接口转换成客户希望的另外一个接口。适配器模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。
**主要解决：**主要解决在软件系统中，常常要将一些"现存的对象"放到新的环境中，而新环境要求的接口是现对象不能满足的。
4.1.1类图
classDiagram
class InterfaceA {
}
<<interface>> InterfaceA
class InterfaceB {
}
<<interface>> InterfaceB
Adapter ..|> InterfaceA
Adapter ..> InterfaceB
Client ..> Adapter
Client ..> InterfaceB
类适配器：以类给到，在Adapter里，就是将src当做类，继承
对象适配器：以对象给到，在Adapter里，将src作为一个对象，持有
接口适配器：以接口给到，在Adapter里，将src作为一个接口，实现
安卓适配器类：BaseAdapter 把数据源转换成View显示.
4.1.2 缺省适配器模式 Default Adapter Pattern
当不需要全部实现接口提供的方法时，可先设计一个抽象类实现接口，并为该接口中每个方法提供一个默认实现（空方法），那么该抽象类的子类可有选择地覆盖父类的某些方法来实现需求。
安卓sdk里的缺省适配器示例
public abstract class AnimatorListenerAdapter implements Animator.AnimatorListener,
Animator.AnimatorPauseListener {
@Override
public void onAnimationCancel(Animator animation) {
}
@Override
public void onAnimationEnd(Animator animation) {
}
@Override
public void onAnimationRepeat(Animator animation) {
}
@Override
public void onAnimationStart(Animator animation) {
}
@Override
public void onAnimationPause(Animator animation) {
}
@Override
public void onAnimationResume(Animator animation) {
}
}
4.2 桥接模式 Bridge Pattern
桥接（Bridge）是用于把抽象化与实现化解耦，使得二者可以独立变化。这种类型的设计模式属于结构型模式，它通过提供抽象化和实现化之间的桥接结构，来
实现二者的解耦。这种模式涉及到一个作为桥接的接口，使得实体类的功能独立于接口实现类。这两种类型的类可被结构化改变而互不影响。
**意图：**将抽象部分与实现部分分离，使它们都可以独立的变化。（一定会有两个独立的抽象/接口，然后桥接（一个组合另外一个类）在一起）
**主要解决：**在有多种可能会变化的情况下，用继承会造成类爆炸问题，扩展起来不灵活。
**何时使用：**实现系统可能有多个角度分类，每一种角度都可能变化。
**如何解决：**把这种多角度分类分离出来，让它们独立变化，减少它们之间耦合。
4.2.1示例说明
以画图为例。Shape是图形的基类，有一个draw方法，子类继承并实现draw方法，调用相应子类，就画出相应的图形。
如果需求变更，可以画出指定颜色的相应图形（七个颜色七种类型，就会有7x7=49个类）。如果继续用继承来实现，会出现非常多的类，类爆炸。
所以应该抽象出Shape和Color两个抽象层，把抽象层和实现层解耦。(用组合代替继承处理类爆炸问题。)
classDiagram
Client ..> Shape
Shape <|-- CircleShape
Shape <|-- RectangleShape
Shape <|-- OvalShape
CircleShape <|-- RedCircleShape
CircleShape <|-- GreenCircleShape
CircleShape <|-- BlueCircleShape
RectangleShape <|-- RedRectangleShape
RectangleShape <|-- GreenRectangleShape
RectangleShape <|-- BlueRectangleShape
OvalShape <|-- RedOvalShape
OvalShape <|-- GreenOvalShape
OvalShape <|-- BlueOvalShape
class Shape {
+ draw()
}
<<interface>> Shape
优化后类图
classDiagram
class ColorPaint {
- Shape shape
+ draw()
}
<<interface>> ColorPaint
ColorPaint <|-- RedPaint
ColorPaint <|-- GreenPaint
ColorPaint <|-- BluePaint
Shape <|-- CircleShape
Shape <|-- RectangleShape
Shape <|-- OvalShape
ColorPaint *-- Shape
4.2.2 其他应用场景
银行转账系统 转帐类型与用户类型
转账分类: 网上转账，柜台转账，AMT转账
转账用户类型：普通用户，银卡用户，金卡用户..
-消息管理 类型与分类
消息类型：即时消息，延时消息
消息分类：手机短信，邮件消息，QQ消息...
4.3 装饰模式 Decorator Pattern
装饰器模式（Decorator Pattern）允许向一个现有的对象添加新的功能，同时又不改变其结构。这种类型的设计模式属于结构型模式，它是作为现有的类的一个包装。
这种模式创建了一个装饰类，用来包装原有的类，并在保持类方法签名完整性的前提下，提供了额外的功能。
**意图：**动态地给一个对象添加一些额外的职责。就增加功能来说，装饰器模式相比生成子类更为灵活。
**主要解决：**一般的，我们为了扩展一个类经常使用继承方式实现，由于继承为类引入静态特征，并且随着扩展功能的增多，子类会很膨胀。
**何时使用：**在不想增加很多子类的情况下扩展类。
**如何解决：**将具体功能职责划分，同时继承装饰者模式。
装饰者模式：动态的将新功能附加到对象上。在对象功能扩展方面，它比继承更有弹性，装饰者模式也体现了开闭原则(ocp)
要点:既继承也组合同一个类，附加功能到原来的类上。
4.3.1 代码示例
jdk里的装饰者模式示例
package java.io;
import java.util.ArrayList;
import java.util.Arrays;
import java.util.List;
import java.util.Objects;
public abstract class InputStream implements Closeable {
private static final int MAX_SKIP_BUFFER_SIZE = 2048;
private static final int DEFAULT_BUFFER_SIZE = 8192;
public static InputStream nullInputStream() {
return new InputStream() {
....
};
}
public abstract int read() throws IOException;
public int read(byte b[]) throws IOException {
return read(b, 0, b.length);
}
....
}
//BufferedInputStream既然是InputStream的子类，也通过构造函数组合了InputStream，增加InputStream的功能。
package java.io;
import jdk.internal.misc.Unsafe;
public
class BufferedInputStream extends FilterInputStream {
private static int DEFAULT_BUFFER_SIZE = 8192;
private static int MAX_BUFFER_SIZE = Integer.MAX_VALUE - 8;
private static final Unsafe U = Unsafe.getUnsafe();
private static final long BUF_OFFSET
= U.objectFieldOffset(BufferedInputStream.class, "buf");
protected volatile byte[] buf;
protected int count;
protected int pos;
protected int markpos = -1;
protected int marklimit;
private InputStream getInIfOpen() throws IOException {
InputStream input = in;
if (input == null)
throw new IOException("Stream closed");
return input;
}
private byte[] getBufIfOpen() throws IOException {
byte[] buffer = buf;
if (buffer == null)
throw new IOException("Stream closed");
return buffer;
}
public BufferedInputStream(InputStream in) {
this(in, DEFAULT_BUFFER_SIZE);
}
public BufferedInputStream(InputStream in, int size) {
super(in);
if (size <= 0) {
throw new IllegalArgumentException("Buffer size <= 0");
}
buf = new byte[size];
}
private void fill() throws IOException {
byte[] buffer = getBufIfOpen();
if (markpos < 0)
pos = 0; /* no mark: throw away the buffer */
else if (pos >= buffer.length) /* no room left in buffer */
if (markpos > 0) { /* can throw away early part of the buffer */
int sz = pos - markpos;
System.arraycopy(buffer, markpos, buffer, 0, sz);
pos = sz;
markpos = 0;
} else if (buffer.length >= marklimit) {
markpos = -1; /* buffer got too big, invalidate mark */
pos = 0; /* drop buffer contents */
} else if (buffer.length >= MAX_BUFFER_SIZE) {
throw new OutOfMemoryError("Required array size too large");
} else { /* grow buffer */
int nsz = (pos <= MAX_BUFFER_SIZE - pos) ?
pos * 2 : MAX_BUFFER_SIZE;
if (nsz > marklimit)
nsz = marklimit;
byte[] nbuf = new byte[nsz];
System.arraycopy(buffer, 0, nbuf, 0, pos);
if (!U.compareAndSetObject(this, BUF_OFFSET, buffer, nbuf)) {
// Can't replace buf if there was an async close.
// Note: This would need to be changed if fill()
// is ever made accessible to multiple threads.
// But for now, the only way CAS can fail is via close.
// assert buf == null;
throw new IOException("Stream closed");
}
buffer = nbuf;
}
count = pos;
int n = getInIfOpen().read(buffer, pos, buffer.length - pos);
if (n > 0)
count = n + pos;
}
public synchronized int read() throws IOException {
if (pos >= count) {
fill();
if (pos >= count)
return -1;
}
return getBufIfOpen()[pos++] & 0xff;
}
private int read1(byte[] b, int off, int len) throws IOException {
int avail = count - pos;
if (avail <= 0) {
/* If the requested length is at least as large as the buffer, and
if there is no mark/reset activity, do not bother to copy the
bytes into the local buffer. In this way buffered streams will
cascade harmlessly. */
if (len >= getBufIfOpen().length && markpos < 0) {
return getInIfOpen().read(b, off, len);
}
fill();
avail = count - pos;
if (avail <= 0) return -1;
}
int cnt = (avail < len) ? avail : len;
System.arraycopy(getBufIfOpen(), pos, b, off, cnt);
pos += cnt;
return cnt;
}
public synchronized int read(byte b[], int off, int len)
throws IOException
{
getBufIfOpen(); // Check for closed stream
if ((off | len | (off + len) | (b.length - (off + len))) < 0) {
throw new IndexOutOfBoundsException();
} else if (len == 0) {
return 0;
}
int n = 0;
for (;;) {
int nread = read1(b, off + n, len - n);
if (nread <= 0)
return (n == 0) ? nread : n;
n += nread;
if (n >= len)
return n;
// if not closed but no bytes available, return
InputStream input = in;
if (input != null && input.available() <= 0)
return n;
}
}
public synchronized long skip(long n) throws IOException {
getBufIfOpen(); // Check for closed stream
if (n <= 0) {
return 0;
}
long avail = count - pos;
if (avail <= 0) {
// If no mark position set then don't keep in buffer
if (markpos <0)
return getInIfOpen().skip(n);
// Fill in buffer to save bytes for reset
fill();
avail = count - pos;
if (avail <= 0)
return 0;
}
long skipped = (avail < n) ? avail : n;
pos += skipped;
return skipped;
}
public synchronized int available() throws IOException {
int n = count - pos;
int avail = getInIfOpen().available();
return n > (Integer.MAX_VALUE - avail)
? Integer.MAX_VALUE
: n + avail;
}
public synchronized void mark(int readlimit) {
marklimit = readlimit;
markpos = pos;
}
public synchronized void reset() throws IOException {
getBufIfOpen(); // Cause exception if closed
if (markpos < 0)
throw new IOException("Resetting to invalid mark");
pos = markpos;
}
public boolean markSupported() {
return true;
}
public void close() throws IOException {
...
}
}
4.3.2 类图
classDiagram
Client ..> Decorator
Decorator <|-- Component
Decorator *-- Component
class Decorator {
- Component component
}
4.4 组合模式 Composite Pattern
4.4.1基本介绍
组合模式（Composite Pattern），又叫部分整体模式，是用于把一组相似的对象当作一个单一的对象。组合模式依据树形结构来组合对象，用来表示部分以及整体层次。这种类型的设计模式属于结构型模式，它创建了对象组的树形结构。
这种模式创建了一个包含自己对象组的类。该类提供了修改相同对象组的方式。
适合有层级关系的对象组合，
例如学校
学校下有多个学院,学院下有多个系
**意图：**将对象组合成树形结构以表示"部分-整体"的层次结构。组合模式使得用户对单个对象和组合对象的使用具有一致性。
**主要解决：**它在我们树型结构的问题中，模糊了简单元素和复杂元素的概念，客户程序可以像处理简单元素一样来处理复杂元素，从而使得客户程序与复杂元素的内部结构解耦。
4.4.2 类图
classDiagram
Client *.. FirstLevel
FirstLevel *.. SecondLevel
SecondLevel *.. ThirdLevel
class FirstLevel {
- List~SecondLevel~
}
class SecondLevel {
- List~ThirdLevel~ thirdLevels
}
4.5 外观模式/门面模式 Facade Pattern
4.5.1 基本介绍
外观模式（Facade Pattern）隐藏系统的复杂性，并向客户端提供了一个客户端可以访问系统的接口。这种类型的设计模式属于结构型模式，它向现有的系统添加一个接口，来隐藏系统的复杂性。
- 外观模式对外屏蔽了子系统的细节，因此外观模式降低了客户端对子系统使用的复
杂性
-
外观模式对客户端与子系统的耦合关系，让子系统内部的模块更易维护和扩展
-
通过合理的使用外观模式，可以帮我们更好的划分访问的层次
-
当系统需要进行分层设计时，可以考虑使用Facade模式
-
在维护一个遗留的大型系统时，可能这个系统已经变得非常难以维护和扩展，此时
可以考虑为新系统开发一个Facade类，来提供遗留系统的比较清晰简单的接口，
让新系统与Facade类交互，提高复用性
- 不能过多的或者不合理的使用外观模式，使用外观模式好，还是直接调用模块好。
要以让系统有层次，利于维护为目的。
4.5.2 不使用外观模式
flowchart TB
Client --> System1
Client --> System2
Client --> System3
Client --> System4
subgraph 系统外需要与系统内的多个子系统直接打交道
Client
end
subgraph 系统内有多个子系统
System1
System2
System3
System4
end
4.5.3 使用外观模式后
flowchart TB
Client --> Facade
Facade --> System1
Facade --> System2
Facade --> System3
Facade --> System4
subgraph 系统外只需要与Facade打交道
Client
end
subgraph 系统内有多个子系统由Facade封装
Facade
System1
System2
System3
System4
end
4.5.4 代码示例
package com.atguigu.facade;
public class HomeTheaterFacade {
//定义各个子系统对象
private TheaterLight theaterLight;
private Popcorn popcorn;
private Stereo stereo;
private Projector projector;
private Screen screen;
private DVDPlayer dVDPlayer;
//构造器
public HomeTheaterFacade() {
super();
this.theaterLight = TheaterLight.getInstance();
this.popcorn = Popcorn.getInstance();
this.stereo = Stereo.getInstance();
this.projector = Projector.getInstance();
this.screen = Screen.getInstance();
this.dVDPlayer = DVDPlayer.getInstanc();
}
//操作分成 4 步
public void ready() {
popcorn.on();
popcorn.pop();
screen.down();
projector.on();
stereo.on();
dVDPlayer.on();
theaterLight.dim();
}
public void play() {
dVDPlayer.play();
}
public void pause() {
dVDPlayer.pause();
}
public void end() {
popcorn.off();
theaterLight.bright();
screen.up();
projector.off();
stereo.off();
dVDPlayer.off();
}
}
4.5.5 安卓sdk里门面模式示例
安卓里的Context
类图
flowchart TB
Client --> Context
Context --> AssetManager
Context --> Resources
Context --> PackageManager
Context --> ContentResolver
Context --> SharedPreferences
Context --> FileInputStream
Context --> sendBroadcast
Context --> startActivities
Context --> startService
subgraph 系统外需要与系统内的多个子系统直接打交道
Client
end
subgraph 系统内有多个子系统由Facade封装
Client
AssetManager
Resources
PackageManager
ContentResolver
SharedPreferences
FileInputStream
sendBroadcast
startActivities
startService
end
4.6 享元模式 Flyweight Pattern
4.6.1 基本介绍
**意图：**运用共享技术有效地支持大量细粒度的对象。
**主要解决：**在有大量对象时，有可能会造成内存溢出，我们把其中共同的部分抽象出来，如果有相同的业务请求，直接返回在内存中已有的对象，避免重新创建。
何时使用： 1、系统中有大量对象。 2、这些对象消耗大量内存。 3、这些对象的状态大部分可以外部化。 4、这些对象可以按照内蕴状态分为很多组，当把外蕴对象从对象中剔除出来时，每一组对象都可以用一个对象来代替。 5、系统不依赖于这些对象身份，这些对象是不可分辨的。
**如何解决：**用唯一标识码判断，如果在内存中有，则返回这个唯一标识码所标识的对象。
**关键代码：**用 HashMap/常量池 存储这些对象。
4.6.2 jdk里的享元模式示例
Integer i = 100;
Integer j = 100;
System.out.println(i.hashCode()==j.hashCode());//true
System.out.println(i ==j);//true
Integer i = 100;
Integer j = 200;
System.out.println(i.hashCode()==j.hashCode());//false
System.out.println(i ==j);//false
从Integer.valueOf()分析Integer常量池
静态内部类里面的静态代码块里初始化好常量池。
public final class Integer extends Number implements Comparable<Integer> {
private static class IntegerCache {
static final int low = -128;
static final int high;
static final Integer cache[];
static {
// high value may be configured by property
int h = 127;
String integerCacheHighPropValue =
VM.getSavedProperty("java.lang.Integer.IntegerCache.high");
if (integerCacheHighPropValue != null) {
try {
int i = parseInt(integerCacheHighPropValue);
i = Math.max(i, 127);
// Maximum array size is Integer.MAX_VALUE
h = Math.min(i, Integer.MAX_VALUE - (-low) -1);
} catch( NumberFormatException nfe) {
// If the property cannot be parsed into an int, ignore it.
}
}
high = h;
cache = new Integer[(high - low) + 1];
int j = low;
for(int k = 0; k < cache.length; k++)
cache[k] = new Integer(j++);
// range [-128, 127] must be interned (JLS7 5.1.7)
assert IntegerCache.high >= 127;
}
private IntegerCache() {}
}
/**
* Returns an {@code Integer} instance representing the specified
* {@code int} value. If a new {@code Integer} instance is not
* required, this method should generally be used in preference to
* the constructor {@link #Integer(int)}, as this method is likely
* to yield significantly better space and time performance by
* caching frequently requested values.
*
* This method will always cache values in the range -128 to 127,
* inclusive, and may cache other values outside of this range.
*
* @param i an {@code int} value.
* @return an {@code Integer} instance representing {@code i}.
* @since 1.5
*/
@HotSpotIntrinsicCandidate
public static Integer valueOf(int i) {
if (i >= IntegerCache.low && i <= IntegerCache.high)
return IntegerCache.cache[i + (-IntegerCache.low)];
return new Integer(i);
}
}
4.7 代理模式 Proxy Pattern
4.7.1 基本介绍
在代理模式（Proxy Pattern）中，一个类代表另一个类的功能。这种类型的设计模式属于结构型模式。
在代理模式中，我们创建具有现有对象的对象，以便向外界提供功能接口。
**意图：**为其他对象提供一种代理以控制对这个对象的访问。
**主要解决：**在直接访问对象时带来的问题，比如说：要访问的对象在远程的机器上。在面向对象系统中，有些对象由于某些原因（比如对象创建开销很大，或者某些操作需要安全控制，或者需要进程外的访问），直接访问会给使用者或者系统结构带来很多麻烦，我们可以在访问此对象时加上一个对此对象的访问层。
**何时使用：**想在访问一个类时做一些控制。
**如何解决：**增加中间层。
**关键代码：**实现与被代理类组合。
4.7.2 装饰模式和代理模式的区别
对装饰器模式来说，装饰者（decorator）和被装饰者（decoratee）都实现同一个 接口。对代理模式来说，代理类（proxy class）和真实处理的类（real class）都实现同一个接口。他们之间的边界确实比较模糊，两者都是对类的方法进行扩展，具体区别如下：
1、装饰器模式强调的是增强自身，在被装饰之后你能够在被增强的类上使用增强后的功能。增强后你还是你，只不过能力更强了而已；代理模式强调要让别人帮你去做一些本身与你业务没有太多关系的职责（记录日志、设置缓存）。代理模式是为了实现对象的控制，因为被代理的对象往往难以直接获得或者是其内部不想暴露出来。
2、装饰模式是以对客户端透明的方式扩展对象的功能，是继承方案的一个替代方案；代理模式则是给一个对象提供一个代理对象，并由代理对象来控制对原有对象的引用；
3、装饰模式是为装饰的对象增强功能；而代理模式对代理的对象施加控制，但不对对象本身的功能进行增强；
4.7.3 静态代理
这里真的和装饰模式一模一样。代理和被代理类都实现相同的接口，并且代理类组合被代理类。
//接口
public interface ITeacherDao {
void teach(); // 授课的方法
}
//被代理的类。
public class TeacherDao implements ITeacherDao {
@Override
public void teach() {
// TODO Auto-generated method stub
System.out.println(" 老师授课中 。。。。。");
}
}
//代理类
//代理对象,静态代理
public class TeacherDaoProxy implements ITeacherDao{
private ITeacherDao target; // 目标对象，通过接口来聚合
//构造器
public TeacherDaoProxy(ITeacherDao target) {
this.target = target;
}
@Override
public void teach() {
// TODO Auto-generated method stub
System.out.println("开始代理 完成某些操作。。。。。 ");//方法
target.teach();
System.out.println("提交。。。。。");//方法
}
}
public class Client {
public static void main(String[] args) {
// TODO Auto-generated method stub
//创建目标对象(被代理对象)
TeacherDao teacherDao = new TeacherDao();
//创建代理对象, 同时将被代理对象传递给代理对象
TeacherDaoProxy teacherDaoProxy = new TeacherDaoProxy(teacherDao);
//通过代理对象，调用到被代理对象的方法
//即：执行的是代理对象的方法，代理对象再去调用目标对象的方法
teacherDaoProxy.teach();
}
}
4.7.4 静态代理类图
classDiagram
Client ..> ProxyClass
ProxyClass <|-- Class
ProxyClass *-- Class
class ProxyClass {
- Class class
}
4.7.5 动态代理
动态代理也叫做：JDK代理、接口代理
代理对象,不需要实现接口，但是目标对象要实现接口，否则不能用动态代理
4.7.6 动态代理代码示例
public class ProxyFactory {
//维护一个目标对象 , Object
private Object target;
//构造器 ， 对target 进行初始化
public ProxyFactory(Object target) {
this.target = target;
}
//给目标对象 生成一个代理对象
public Object getProxyInstance() {
//说明
/*
* public static Object newProxyInstance(ClassLoader loader,
Class<?>[] interfaces,
InvocationHandler h)
//1. ClassLoader loader ： 指定当前目标对象使用的类加载器, 获取加载器的方法固定
//2. Class<?>[] interfaces: 目标对象实现的接口类型，使用泛型方法确认类型
//3. InvocationHandler h : 事情处理，执行目标对象的方法时，会触发事情处理器方法, 会把当前执行的目标对象方法作为参数传入
*/
return Proxy.newProxyInstance(target.getClass().getClassLoader(),
target.getClass().getInterfaces(),
new InvocationHandler() {
@Override
public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
// TODO Auto-generated method stub
System.out.println("JDK代理开始~~");
//反射机制调用目标对象的方法
Object returnVal = method.invoke(target, args);
System.out.println("JDK代理提交");
return returnVal;
}
});
}
}
4.7.7 Cglib代理 （Code Generation Library）
- 静态代理和JDK代理模式都要求目标对象是实现一个接口,但是有时候目标对象只是一个单独的对象,并没有实现任何的接口,这个时候可使用目标对象子类来实现
代理-这就是Cglib代理
-
Cglib代理也叫作子类代理,它是在内存中构建一个子类对象从而实现对目标对象功能扩展, 有些书也将Cglib代理归属到动态代理。
-
Cglib是一个强大的高性能的代码生成包,它可以在运行期扩展java类与实现java接口.它广泛的被许多AOP的框架使用,例如Spring AOP，实现方法拦截
-
在AOP编程中如何选择代理模式：
-
目标对象需要实现接口，用JDK代理
-
目标对象不需要实现接口，用Cglib代理
- Cglib包的底层是通过使用字节码处理框架ASM来转换字节码并生成新的类
需要依赖的包有
asm.jar
asm-commons.jar
asm-tree.jar
cglib-2.2.jar
4.7.8 kotlin里的 委托模式 Delegation Pattern
interface SoundBehavior { // 1
fun makeSound()
}
class ScreamBehavior(val n:String): SoundBehavior { // 2
override fun makeSound() = println("${n.toUpperCase()} !!!")
}
class RockAndRollBehavior(val n:String): SoundBehavior { // 2
override fun makeSound() = println("I'm The King of Rock 'N' Roll: $n")
}
// Tom Araya is the "singer" of Slayer
class TomAraya(n:String): SoundBehavior by ScreamBehavior(n) // 3
// You should know ;)
class ElvisPresley(n:String): SoundBehavior by RockAndRollBehavior(n) // 3
fun main() {
val tomAraya = TomAraya("Thrash Metal")
tomAraya.makeSound() // 4
val elvisPresley = ElvisPresley("Dancin' to the Jailhouse Rock.")
elvisPresley.makeSound()
}
//代理强化，要代理的对象，由外部实例化后传入
class ElvisPresley2(val soundBehavior: SoundBehavior):SoundBehavior by soundBehavior {
//代理加强
override fun makeSound() {
println("makeSound start")
soundBehavior.makeSound();
println("makeSound end")
}
}
