内容摘自《图解设计模式》
Iterator模式
作用：遍历
将for循环中的i抽象化、通用化形成了Iterator模式
hasNext():判断是否存在下一个元素，即确认接下来是否可以调用next方法
next():获取下一个元素（返回当前元素并且将指向下一个元素）
为什么要引入Iterator:
将实现和遍历分离开。
这里只使用了 Iterator的hasNext 方法和next 方法，并没有调用 BookShelf 的方法，即这里的while循环并不依赖于 BookShelf 的实现，无论是用数组还是vector来管理书本，只要 BookShelf 的 iterator方法能正确地返回 Iterator 的实例（也就是说，返回的Iterator 类的实例没有问题，hasNext和next方法都可以正常工作），都不会影响遍历。
丰富的Iterator:
- 可以针对一个ConcreteAggregate角色编写多个ConcreteIterator角色
- 可以根据需要采取多种多样的遍历方式，从后往前/跳跃式balabala
Adapter模式（又名Wrapper模式）
- 类适配器模式（使用继承）
- 对象适配器模式（使用委托）
类适配器模式（使用继承）
Banner：现有的实际情况，本来就有的类Adpat-ee
Print:需求的接口
PrintBanner:Adapter,继承自Banner,实现Print，符合开闭原则，不用修改banner类就能实现print需求,Adapt-er
⬆️图片来自https://blog.csdn.net/shiaiao/article/details/118544760
对象适配器模式（使用委托）
Main
什么时候用Adapter
很多时候，我们并非从零开始编程，经常会用到现有的类。特别是当现有的类已经被充分测试过了，Bug 很少，而且己经被用于其他软件之中时，我们更愿意将这些类作为组件重复利用。
Adapter模式会对现有的类进行适配，生成新的类。通过该模式可以很方便地创建我们需要的方法群。当出现 Bug 时，由于我们很明确地知道 Bug 不在现有的类（ Adaptee 角色）中，所以只需调查扮演 Adapter 角色的类即可。这样一来，代码问题的排查就会变得非常简单。
让现有的类适配新的接口（API）时，使用 Adapter 模式似乎是理所当然的。不过实际上，我们
在让现有的类适配新的接口时，常常会有“只要将这里稍微修改下就可以了” 的想法，一不留神就会修改现有的代码。但是需要注意的是，如果要对已经测试完毕的现有代码进行修改，就必须在修改后重新进行测试。
使用 Adapter 模式可以在完全不改交现有代码的前提下使现有代码适配于新的接口（API)。此外，
在 Adapter 模式中，并非一定需要现成的代码。只要知道现有类的功能，就可以编写出新的类。
软件的生命周期总是伴随着版本的升级，而在版本升级的时候经常会出现“与旧版本的兼容
性”问题。如果能够完全拋弃旧版本，那么软件的维护工作将会轻松得多，但是现实中往往无法这
样做。这时，可以使用 Adapter 模式使新旧版本兼容，帮助我们轻松地同时维护新版本和旧版本。
例如，假设我们今后只想维护新版本。这时可以让新版本扮演 Adaptee 角色，旧版本扮演
Target 角色。接着编写一个扮演 Adapter 角色的类，让它使用新版本的类来实现旧版本的类中的
方法。
