设计模式之结构型模式

1、概述：

适配器模式（Adapter）的定义如下：将一个类的接口转换成客户希望的另外一个接口，使得原本由于接口不兼容而不能一起工作的那些类能一起工作。适配器模式分为类结构型模式和对象结构型模式两种，前者类之间的耦合度比后者高，且要求程序员了解现有组件库中的相关组件的内部结构，所以应用相对较少些。

2、主要角色：

①、目标（Target）接口：当前系统业务所期待的接口，它可以是抽象类或接口。

②、适配者（Adaptee）类：它是被访问和适配的现存组件库中的组件接口。

③、适配器（Adapter）类：它是一个转换器，通过继承或引用适配者的对象，把适配者接口转换成目标接口，让客户按目标接口的格式访问适配者。

3、应用场景****：****

①、系统需要使用一些现有的类，而这些类的接口（如方法名）不符合系统的需要，甚至没有这些类的源代码。

②、想创建一个可以重复使用的类，用于与一些彼此之间没有太大关联的一些类，包括一些可能在将来引进的类一起工作。

4、优点：

①、客户端通过适配器可以透明地调用目标接口。

②、复用了现存的类，程序员不需要修改原有代码而重用现有的适配者类。

③、将目标类和适配者类解耦，解决了目标类和适配者类接口不一致的问题。

④、在很多业务场景中符合开闭原则。

5、缺点：

①、适配器编写过程需要结合业务场景全面考虑，可能会增加系统的复杂性。

②、增加代码阅读难度，降低代码可读性，过多使用适配器会使系统代码变得凌乱。

桥接********模式

1、概述：

桥接（Bridge）模式的定义如下：将抽象与实现分离，使它们可以独立变化。它是用组合关系代替继承关系来实现，从而降低了抽象和实现这两个可变维度的耦合度。

2、主要角色：

①、抽象化（Abstraction）角色：定义抽象类，并包含一个对实现化对象的引用。

②、扩展抽象化（Refined Abstraction）角色：是抽象化角色的子类，实现父类中的业务方法，并通过组合关系调用实现化角色中的业务方法。

③、实现化（Implementor）角色：定义实现化角色的接口，供扩展抽象化角色调用。

④、具体实现化（Concrete Implementor）角色：给出实现化角色接口的具体实现。

3、应用场景****：****

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

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

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

4、优点：

①、抽象与实现分离，扩展能力强

②、符合开闭原则

③、符合合成复用原则

④、其实现细节对客户透明

5、缺点：

由于聚合关系建立在抽象层，要求开发者针对抽象化进行设计与编程，能正确地识别出系统中两个独立变化的维度，这增加了系统的理解与设计难度。

装饰********模式

1、概述：

装饰器（Decorator）模式的定义：指在不改变现有对象结构的情况下，动态地给该对象增加一些职责（即增加其额外功能）的模式，它属于对象结构型模式。

2、主要角色：

①、抽象构件（Component）角色：定义一个抽象接口以规范准备接收附加责任的对象。

②、具体构件（ConcreteComponent）角色：实现抽象构件，通过装饰角色为其添加一些职责。

③、抽象装饰（Decorator）角色：继承抽象构件，并包含具体构件的实例，可以通过其子类扩展具体构件的功能。

④、具体装饰（ConcreteDecorator）角色：实现抽象装饰的相关方法，并给具体构件对象添加附加的责任。

3、应用场景****：****

①、当需要给一个现有类添加附加职责，而又不能采用生成子类的方法进行扩充时。例如，该类被隐藏或者该类是终极类或者采用继承方式会产生大量的子类。

②、当需要通过对现有的一组基本功能进行排列组合而产生非常多的功能时，采用继承关系很难实现，而采用装饰器模式却很好实现。

③、当对象的功能要求可以动态地添加，也可以再动态地撤销时。

4、优点：

①、装饰器是继承的有力补充，比继承灵活，在不改变原有对象的情况下，动态的给一个对象扩展功能，即插即用

②、通过使用不用装饰类及这些装饰类的排列组合，可以实现不同效果

装饰器模式完全遵守开闭原则

5、缺点：

装饰器模式会增加许多子类，过度使用会增加程序得复杂性。

外观********模式

1、概述：

外观（Facade）模式又叫作门面模式，是一种通过为多个复杂的子系统提供一个一致的接口，而使这些子系统更加容易被访问的模式。该模式对外有一个统一接口，外部应用程序不用关心内部子系统的具体细节，这样会大大降低应用程序的复杂度，提高了程序的可维护性。

2、主要角色：

①、外观（Facade）角色：为多个子系统对外提供一个共同的接口。

②、子系统（Sub System）角色：实现系统的部分功能，客户可以通过外观角色访问它。

③、客户（Client）角色：通过一个外观角色访问各个子系统的功能。

3、应用场景****：****

①、对分层结构系统构建时，使用外观模式定义子系统中每层的入口点可以简化子系统之间的依赖关系。

②、当一个复杂系统的子系统很多时，外观模式可以为系统设计一个简单的接口供外界访问。

③、当客户端与多个子系统之间存在很大的联系时，引入外观模式可将它们分离，从而提高子系统的独立性和可移植性。

4、优点：

①、降低了子系统与客户端之间的耦合度，使得子系统的变化不会影响调用它的客户类。

②、对客户屏蔽了子系统组件，减少了客户处理的对象数目，并使得子系统使用起来更加容易。

③、降低了大型软件系统中的编译依赖性，简化了系统在不同平台之间的移植过程，因为编译一个子系统不会影响其他的子系统，也不会影响外观对象。

5、缺点：

①、不能很好地限制客户使用子系统类，很容易带来未知风险。

②、增加新的子系统可能需要修改外观类或客户端的源代码，违背了“开闭原则”。

享元********模式

1、概述：

享元（Flyweight）模式的定义：运用共享技术来有效地支持大量细粒度对象的复用。它通过共享已经存在的对象来大幅度减少需要创建的对象数量、避免大量相似类的开销，从而提高系统资源的利用率。

2、主要角色：

①、抽象享元角色（Flyweight）：是所有的具体享元类的基类，为具体享元规范需要实现的公共接口，非享元的外部状态以参数的形式通过方法传入。

②、具体享元（Concrete Flyweight）角色：实现抽象享元角色中所规定的接口。

非享元（Unsharable Flyweight)角色：是不可以共享的外部状态，它以参数的形式注入具体享元的相关方法中。

③、享元工厂（Flyweight Factory）角色：负责创建和管理享元角色。当客户对象请求一个享元对象时，享元工厂检査系统中是否存在符合要求的享元对象，如果存在则提供给客户；如果不存在的话，则创建一个新的享元对象。

3、应用场景****：****

①、系统中存在大量相同或相似的对象，这些对象耗费大量的内存资源。

②、大部分的对象可以按照内部状态进行分组，且可将不同部分外部化，这样每一个组只需保存一个内部状态。

③、由于享元模式需要额外维护一个保存享元的数据结构，所以应当在有足够多的享元实例时才值得使用享元模式。

4、优点：

相同对象只要保存一份，这降低了系统中对象的数量，从而降低了系统中细粒度对象给内存带来的压力。

5、缺点：

①、为了使对象可以共享，需要将一些不能共享的状态外部化，这将增加程序的复杂性。

结语

网上高级工程师面试相关文章鱼龙混杂，要么一堆内容，要么内容质量太浅， 鉴于此我整理了上述安卓开发高级工程师面试题以及答案。希望帮助大家顺利进阶为高级工程师。
目前我就职于某大厂安卓高级工程师职位，在当下大环境下也想为安卓工程师出一份力，通过我的技术经验整理了面试经常问的题，答案部分是一篇文章或者几篇文章，都是我认真看过并且觉得不错才整理出来。

大家知道高级工程师不会像刚入门那样被问的问题一句话两句话就能表述清楚，所以我通过过滤好文章来帮助大家理解。

现在都说互联网寒冬，其实只要自身技术能力够强，咱们就不怕！我这边专门针对Android开发工程师整理了一套【Android进阶学习视频】、【全套Android面试秘籍】、【Android知识点PDF】。

《Android学习笔记总结+移动架构视频+大厂面试真题+项目实战源码》，点击传送门，即可获取！
份力，通过我的技术经验整理了面试经常问的题，答案部分是一篇文章或者几篇文章，都是我认真看过并且觉得不错才整理出来。

大家知道高级工程师不会像刚入门那样被问的问题一句话两句话就能表述清楚，所以我通过过滤好文章来帮助大家理解。

[外链图片转存中…(img-qL5pCZE8-1715394296763)]

现在都说互联网寒冬，其实只要自身技术能力够强，咱们就不怕！我这边专门针对Android开发工程师整理了一套【Android进阶学习视频】、【全套Android面试秘籍】、【Android知识点PDF】。

《Android学习笔记总结+移动架构视频+大厂面试真题+项目实战源码》，点击传送门，即可获取！