1 迭代器模式
解决问题：主要是多个类的话，搜寻出相应的个股并逐个打印出来，这个在调用类的过程中，会产生较多的for循环或者while循环。如果多个调用类的话，在调用类中写不好并且重复多遍。
设计思路：迭代模式，先定义号迭代器接口，里面有循环迭代的接口，然后定义一个迭代器类继承迭代器接口，实现循环迭代的接口。然后在容器接口中调用迭代器的类，以实现循环迭代的效果，再生成一个容器类来继承容器接口来写定义好的方法。最后调用类直接调用容器类提供的接口，即可实现循环遍历查询的目的
常用场景：数据库的cursor游标
github地址：
2 模版方法模式
解决问题：有很多开发中固定的关键步骤，并确定了这些步骤的执行顺序，但是具体步骤会随着环境的变化而变化。譬如电脑开机的步骤：开启电源->硬件检查->加载系统->登录->关闭，程序员的计算机多了一部输入密码登录，军方的计算机多了指纹登录外，不仅要硬件检查，还要加多一部做防火墙检查
设计思路：模版方式模式，先定义一个抽象类，先定义基本的方法，然后最后final一个方法实现按顺序走必须要走的方法；然后根据需求新的类，继承抽象类，重写抽象类中需要增加的方法，如果沿用抽象类的方法，保留 super.fun()，；既走父类的方法，也走自己的方法，在 super.fun() 写新的实现代码；不走父类的方法，直接抹掉 super.fun()
常用场景：AsyncTask
github地址：https://github.com/tjjlhst/JavaDesignProject/tree/master/MasterplateModule
3 访问者模式
解决问题：1、对象结构比较稳定，但经常需要在此对象上定义新的操作 2、需要对一个对象结构中的对象进行很多不同的并且不相关的操作，而需要避免污染这些对象的类，也不希望在增加新操作时修改这些类
设计思路：访问者模式比较复杂，首先定义为角色的分配，以员工和老板为例，cto、ceo = visitor，拥有查看员工信息的权限，经理、工程师 = staff；首先staff被查看者都定义一个可以查看的权限，visitor只有权限才能查看，然后定义子类需要的值，构建经理和工程师两个子类，这两个子类利用staff的值，写各自独有的方法；然后定义接口类visitor的方法，写两个相同的方法visit()，但是传的是两个不同的staff类的参数，然后构建两个继承visitor的ceo和cto类，它们的方法分别是调用查看经理和工程师的信息方法visit() (通过参数的不同来区分)
常用场景：
github地址：https://github.com/tjjlhst/JavaDesignProject/tree/master/AccessModule
4 中介者模式
解决问题：当对象之间的交互操作很多且每个对象的行为都彼此依赖时，为防止在修改一个对象的行为时，同时涉及修改很多其他对象的行为，可用中介模式来解决紧耦合的问题。该模式由多对多变成一对多的关系，将系统从网状结构变成以调停者为中心的星形结构，达到降低系统的复杂性，提高可扩展性的作用
设计思路：将对象的行为和协作抽象化，把对象在小尺度的行为上与其他对象的相互作用分开处理，
常用场景：keyguard锁屏
github地址：
5 代理模式（委托模式）
解决问题：当无法或不想直接访问某个对象或访问某个对象存在困难的时候可以通过一个代理对象来间接访问，为了保证客户端使用的透明性，委托对象与代理对象需要实现相同的接口
设计思路：结构性模式。以讨薪走法律流程为例，1、（静态代理）首先先定义一个接口类，定义好上述固定的步骤: 申诉->举证->辩护->完成 四个方法；定义具体诉讼类，继承诉讼接口类，重写接口类的方法；定义具体代理类，持有一个具体被代理者的引用，实例化代理类时要把诉讼类传进来成为引用，代理类的四个规定步骤，走的全是诉讼类的相同方法（也就是代理类只是作为一个代理转达消息，并没有实质自己要做的事）；调用类用接口类构造一个具体的诉讼类，再创建一个代理类，将构建好的诉讼类传入代理类中，代理按照步骤将方法逐个调用。2、（动态代理）通过反射的机制动态地生成代理者的对象，也就是在code阶段压根不知道代理谁，在有在执行阶段才知道（java提供了动态代理接口InvocationHandler，实现该接口需要重写其调用的invoke()方法）；先声明一个object的引用，该引用将指向被代理类，而我们调用被代理类的具体方法则在invoke方法中执行，实例化动态代理后，继续按步骤调用固定的方法即可
常用场景：Binder跨进程通信机制与AIDL
github地址：https://github.com/tjjlhst/JavaDesignProject/tree/master/ProxyModule
6 组合模式
解决问题：将一组相似的类看作一个对象来处理，并根据一个树状结构来组合对象，然后提供一个统一的方法去访问相应的对象，以此忽略掉对象与对象集合之间的差异。不同的对象根据抽象的基类的抽象方法，定义该对象的类能否实现该功能，譬如文件夹和文件的功能区分，文件夹下能加文件，而文件下不能加文件
设计思路：以文件来举例，先定义抽象的基类Dir，然后定义抽象的方法；定义文件夹类Folder继承Dir，实现Dir类的添加文件、移除文件等方法；定义文件类File继承Dir，实现Dir类的print打印方法，不能实现添加文件、移除文件等方法。在调用类使用时，文件夹下可以添加文件或文件夹，文件下不能添加文件夹或文件
常用场景：View和ViewGroup，vViewGroup有容器的功能
github地址：https://github.com/tjjlhst/JavaDesignProject/tree/master/CompositeModule
7 适配器模式
解决问题：需要对两个无关系的两个类融合到一起，将不同的的东西通过一种转换使它们能够协作起来，listview、recycleview都需要使用到adapter，adapter就是 混血 接口，将两个不同类的两种不同接口进行兼容，在不修改原有代码的情况下满足需求
设计思路：角色介绍：
Target：目标角色，也就是所期待获得的接口
Adaptee：现在需要适配的接口
Adapter：适配器角色，适配器需要把源接口转换成目标接口。所以adapter这一角色不可以是接口，必须是具体类
可以定义多个不同的类，最后都通过adapter统一转成一个结果即可，譬如有5v、110v和220v的输入功率类，但是最后通过自定义adapter均转成5v的结果即可
常用场景：listview和recycleview的adapter使用
github地址：https://github.com/tjjlhst/JavaDesignProject/tree/master/AdapterModule
8 装饰模式
解决问题：动态地给一个对象添加一些额外的职责，就增加功能来说，装饰模式相比生成子类更加灵活。在需要透明且动态地扩展类的功能时
设计思路：角色介绍：
Component：抽象组件：可以是一个接口或抽象类，其充当的就是被装饰的原始对象
ConcreteComponent：组件具体实现类：该类是Component类的基本实现，也是我们装饰的具体对象
Decorator：抽象装饰者：其承担的责任就是为了装饰我们的组件对象，其内部一定有一个指向组件对象的引用，在大多情况下该类为抽象类，需要根据不同的装饰逻辑实现不同的具体子类
ConcreteDecoratorA/ConcreteDecoratorB：具体实现类
常用场景：Context与ContextImpl
github地址：https://github.com/tjjlhst/JavaDesignProject/tree/master/DecoratorModule
9 享元模式
解决问题：对象池的一种实现，轻量级，用来尽可能的减少内存使用量，适用于可能存在大量重复对象的场景，缓存可共享的对象。
设计思路：共享对象分为内部对象和外部对象，可共享的对象称为内部对象，内部对象不会随着环境改变；不可共享的状态称之为外部状态，它们会随着环境变化而变化。在享元模式中会建立一个元对象容器，经典的享元模式中该容器为一个map，键就是享元对象的内部对象，值就是享元对象本身。以买票为例，同一个地点的车辆是有限的，这些就可以存起来，查询的时候直接调用不创建新的对象，先创建一个ticket接口，该接口定义展示车票信息的函数；然后新建一个TicketFactory类，定义一个static方法getTicket(from,to)，这里的from、to拼接就相当于做享元模式的key用，然后用key做判断，如果没有这个key，就新建一个TicketFactory对象返回，如果有，方法直接返回已有的TicketFactory；在测试类中，直接调用TicketFactory类的getTicket(from,to)方法
常用场景：1 存在大量相似的相似对象 2 细粒度的对象都具备接近的外部状态，而且内部状态与环境无关，也就是说对象没有特定身份 3 需要缓冲池的情景
Handler、Message、android消息机制
github地址：https://github.com/tjjlhst/JavaDesignProject/tree/master/FlyweightModule
10 外观观式
解决问题：就是统一接口封装，将子系统的逻辑、交互都隐藏起来，为用户提供了一个高层次的接口，使得系统更加易用，同时也对外隐藏了具体的实现。即使具体的子类发生了改变，用户也不会感知到
设计思路：以手机为例，先建立一个MobilePhone类，它有两个子功能拨号和拍照，MobilePhone可以封装起来提供统一的操作接口，只需要通过MobilePhone就可以打电话和拍照，用户可以忽略子功能背后做的一系列动作；定义一个phone接口和phoneImpl类，实现打电话的功能；定义一个camera接口和cameraImpl类，实现拍照功能；MobilePhone类中创建phone和camera的实类，定义调用它们打电话或拍照的方法，并提供给test类调用，即可。所以内部还可以增加Message接口和MessageImpl类，MobilePhone增加调用的方法，test类也不需要改动，只要调用新增的方法即可
常用场景：Context
github地址：
11 Builder模式
解决问题：是让用户在清楚流程的情况下一步一步创建一个复杂对象的创建模式，可以更精细地控制对象的构造流程。该模式是为了将构建复杂对象的过程和它的部件解耦，使得整个过程和部件的表示隔离开来，使用场景1、相同的方法，不同的执行顺序，产生不同的事件结果时 2、多个部件或零件，都可以装配到一个对象中，但是产生的运行时结果又不相同 3、产品非常复杂，或者产品类中的调用顺序不同产生了不同的作用，这个时候使用建造者模式非常合适 4 初始化一个对象特别复杂，如参数很多，且很多参数都具有默认值时
设计思路：Builder和Director两个类一起将一个复杂对象的构建与分离，director会对builder进行创建并封装起来，但不够灵活；如果需要灵活应用可以直接用builder设置需要的参数；如果builder要做到链式的编程，在builder的每个方法中return this才行
常用场景：AlertDialog.Builder
github地址：https://github.com/tjjlhst/JavaDesignProject/tree/master/BuilderModule
网友评论