结构型模式
(6) 适配器模式：很多足球队都喜欢请外国教练（其中有一支我们都非常熟悉的国家队，名字偶就不说了，大家都懂的，
），外国教练请回来通常很难跟队员直接交流（语言不通），因此需要配翻译，此时，翻译充当了教练和队员之间的适配器，负责协调教练和队员之间的交流。
例如：pass --> shoot --> goal 转换传球 --> 射门 --> 进球
适配器模式(Adapter): 将一个类的接口转换成用户希望的另一个接口，使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。
(7) 桥接模式：在足球比赛中，有人踢前锋、有人踢中场（前腰、中卫）、有人踢后卫；当然，有人习惯踢左边、有人习惯踢右边、也有人喜欢站在中间，因此诞生了左中卫、右前锋、中后卫、右后卫等名词，难道这不是两个变化维度的组合吗？
桥接模式(Bridge): 将抽象部分与实现部分分离，使它们都可以独立地变化。
(8) 组合模式 ：2012年欧洲杯一共分为四个组，每个组四个队，每个队有23名球员，如果要用一个图来表示2012年欧洲杯全体球员及各国分组情况，不用说，一定是个树状图，组里有队，队里有人，如果想要召开B组（赛前公认的死亡之组）队员大会，在B组的节点上写下通知：“下午3点，召开重要会议，事关出线！”，想必荷兰、德国、葡萄牙、丹麦队员都会积极响应，随叫这几个“苦逼”队位于同一个节点的分支上呢？
组合模式(Composite): 将对象组合成树形结构以表示“部分-整体”的层次结构，它使得客户对单个对象和复合对象的使用具有一致性。
(9) 装饰模式 ：现在足球服上的广告越来越多了，2012年欧洲杯夺冠热门之一（赛前预测）德国队队服胸前右边一个奔驰，左边一个阿迪，当然还可以继续增加，广告既没有改变球衣的用途和性能，还能起到装饰效果，增加收入，何乐而不为呢？就是半决赛没能够让巴神继续“思考人生”，悲催的德国队！增加新的广告，只需对原有球服继续装饰即可。
装饰模式(Decorator): 动态地给一个对象添加一些额外的职责，就扩展功能而言， 它比生成子类的方式更为灵活。
(10) 外观模式 ：为了给记者和球队（球员、教练等）提供一个交流的平台，欧洲杯组委会在每场足球比赛前后都安排了新闻发布会，记者可以通过新闻发布会来与球队进行沟通交流（虽然不是每个队员会出现在新闻发布会上），在此，新闻发布会充当了记者（客户端）和队员、教练（子系统）之间的外观角色。当然，新闻发布会并不会影响某位记者单独采访某位球员（这一点也与外观类的定义一致，
）。
外观模式(Facade): 子系统中的一组接口提供一个一致的界面，定义一个高层接口，这个接口使得这一子系统更加容易使用。
(11) 享元模式 ：同一个国家队的队员，他们都共享着一个伟大的称谓，即"XXX国家队队员"，例如“意大利国家队队员”、“西班牙国家队队员”（一说到“中国国家队队员”就伤心，还是不说了，
），因此，"XXX国家队队员"是一个可以共享的内部状态。但是在比赛过程中，每个队员身披不同号码的球衣，球衣号码是不能共享的，同一个国家队的队员每个人都拥有不同的号码，因此，球衣号码是不能够共享的外部状态。在享元模式中区分了对象的内部状态和外部状态。
享元模式(Flyweight): 运用共享技术有效地支持大量细粒度的对象。
(12) 代理模式 ：足球场外，球员转会是一个热门话题。转会当然离不开球员的经纪人，经纪人将球员的想法传递给另一家俱乐部。经纪人就是球员的代理，球员是目标对象，而经纪人是代理对象，经纪人隔离了球员和“客户端”，“拍广告，请找我的经纪人”，“采访，请找我的经纪人”......
代理模式(Proxy)：为其他对象提供一个代理以控制对这个对象的访问。
