使用转接头（适配器）

系统管理员 2022-01-14 10:53 149阅读 0赞

前俩天老妈说从家里抽屉里找到个耳机但是用不了，我让她拍个照片给我看，原来是因为手机是Type-C接口，耳机是3.5mm头的。于是我买了个转接口给她。如下图：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xpdHRlX2Zyb2c_size_16_color_FFFFFF_t_70]  
  本能反应的我，立马开始联想了起来…

--------------------

#### 适配器 ####

###### 情景1 没有耳机 ######

mom的手机

public class MomPhone { 
    
        private TypeC earphone;
    
        public void play(){ 
            if (earphone == null) { 
                System.out.println("loudspeaker play");
            } else { 
                System.out.println(earphone.getType() + " earphone play");
            }
        }
    
        public void connect(TypeC earphone){ 
            this.earphone = earphone;
        }
    }

播放状态是扬声器外放

MomPhone momPhone = new MomPhone();
    momPhone.play(); // loudspeaker play

###### 情景2 连接Type-C接口的华为耳机 ######

public interface TypeC { 
        String getType();
    }
    
    public class TypeCHW implements TypeC { 
        @Override
        public String getType() { 
            return "Huawei";
        }
    }

播放状态是华为耳机播放

momPhone.connect(new TypeCHW());
    momPhone.play(); // Huawei earphone play

###### 情景3 连接3.5mm的JBL耳机 ######

public interface M35 { 
        String getType();
    }
    
    public class M35JBL implements M35 { 
        @Override
        public String getType() { 
            return "JBL";
        }
    }

接口不对应是不能使用的，所以需要一个如图的转接头

public class Adapter implements TypeC{ 
    
        private M35 m35;
    
        public Adapter(M35 m35) { 
            this.m35 = m35;
        }
    
        @Override
        public String getType() { 
            return m35.getType();
        }
    }

转接头需要连接手机，所以必须实现Type-C接口，并且暴露一个3.5mm接口，让3.5mm的设备连接自己，就是Adapter的构造方法。  
  有了转接口就可以播放了

momPhone.connect(new Adapter(new M35JBL()));
    momPhone.play(); // JBL earphone play

#### 适配器模式 ####

情景3中将3.5mm设备通过转接口连接上Type-C接口的设备的过程，就是使用了设计模式中适配器模式，那个转接头就是适配器。  
  适配器模式可以分为类适配、对象适配、接口适配，上面用的就是对象适配。

###### 类适配 ######

public class M35JBLAdapter extends M35JBL implements TypeC { 
        @Override
        public String getType() { 
            return super.getType();
        }
    }

要描述上面这个类，可以理解JBL的厂商将原来的JBL耳机升级为Type-C接口一样，是专门针对M35JBL这款设备做了适配一样。

momPhone.connect(new M35JBLAdapter());
    momPhone.play(); // JBL earphone play

###### 接口适配 ######

这种模式在业务代码中应该很少遇到。大致描述就是说，有一个接口中定义了很多方法，如果想只实现其中部分的话，可以在接口和实现类中增加一层抽象类，抽象类实现接口所有方法，但是都是空实现，自定义类继承抽象类可以重写其中部分方法。

public interface A { 
        void a();
        void b();
        void c();
        void d();
        void e();
        void f();
        void g();
        void h();
    }
    public abstract class AbstractA implements A { 
        public void a() { }
        public void b() { }
        public void c() { }
        public void d() { }
        public void e() { }
        public void f() { }
        public void g() { }
        public void h() { }
    }
    public class AImpl extends AbstractA { 
        public void b() { 
            System.out.println();
        }
        public void e() { 
            System.out.println();
        }
    }

其中的AbstractA类就是适配器。

#### 策略模式 ####

策略模式大多情况用在根据不同角色（或类型）处理不同业务的场景中（比如游客、VIP、活动送的VIP）。举个例子：

if ("tourists".equals(type)) { 
                // 业务a
            } else if ("vip".equals(type)) { 
                // 业务a
            } else if ("presenterVip".equals(type)) { 
                // 业务a
            } else { 
                // 业务a
            }

随着业务代码行数比较多的时候，将每个业务代码提成一个单独的方法，可读性很高。直到增加了一个为 SVIP 的类型，原来的业务方法可能也需要拆分，于是决定将每个方法都独立成一个类。  
![在这里插入图片描述][20190614170214738.PNG]

public interface Role { 
        void run();
    }
    
    public class VIP implements Role { 
        @Override
        public void run() { 
            // vip
        }
    }
    
    public class SVIP implements Role { 
        @Override
        public void run() { 
            // 金主爸爸，什么权限都开
        }
    }
    
    public class Tourists implements Role { 
        @Override
        public void run() { 
            // 穷b，不需要操作
            return;
        }
    }
    
    public class PVIP implements Role{ 
        @Override
        public void run() { 
            // 活动送的vip，只设置头像挂饰
        }
    }

另外定义一个业务类，将业务方法抽取出来

public class RoleService { 
    
        private Role role;
    
        public RoleService(Role role){ 
            this.role = role;
        }
    
        public void run(){ 
            role.run();
        }
    }

最初的调用方式变成了下面这样：

Role role = null;
            if ("tourists".equals(type)) { 
                role = new Tourists();
            } else if ("vip".equals(type)) { 
                role = new VIP();
            } else if ("presenterVip".equals(type)) { 
                role = new PVIP();
            } else if ("svip".equals(type)){ 
                role = new SVIP();
            }
            RoleService roleService = new RoleService(role);
            roleService.run(); // 业务a

如果再次增加一种类型，同样执行业务a，那么扩展Role接口的实现类即可（程序设计开闭原则：对扩展开放，对修改关闭），以上改进流程就是运用了策略设计模式。每种角色有单独的实现类后，其中只包含该角色应该要做的业务，不和其他角色业务混在一起（单一职能原则），降低业务间的耦合。  
  但是貌似这么多if-else还是没有删除，还是要修改if-else内容。其实这块代码可以抽象成工厂方法，需要根据type获取对应角色实现类，用在程序其他地方。

#### 简单工厂模式 ####

public class RoleFactory { 
        
        public static Role create(String type) { 
            if ("tourists".equals(type)) { 
                return new Tourists();
            } else if ("vip".equals(type)) { 
                return new VIP();
            } else if ("presenterVip".equals(type)) { 
                return new PVIP();
            } else if ("svip".equals(type)){ 
                return new SVIP();
            } else { 
                throw new RuntimeException("Type Error");
            }
        }
    }

使用简单工厂

Role role = RoleFactory.create(type);
            RoleService roleService = new RoleService(role);
            roleService.run(); // 业务a

#### 最后 ####

刚开始写代码的时候并不知道设计模式有什么用，感觉花里胡哨还把自己绕晕了，直到在多个项目中由于需求的增加，发现自己写的代码改起来越来越费劲，慢慢的重构改进后，有一天发现自己原来用了设计模式（第一个是策略模式）。那么下次遇到这种业务场景，开始就按一种模式设计后，不论是后期优化还是扩展都很方便，而且代码的可读性也很好。  
  每个人对设计模式态度是不一样的，站的高度不同，看法也不同。“看山是山，看水是水；看山不是山，看水不是水；看山还是山，看水还是水”。不知道自己何时能修炼到那个境界。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xpdHRlX2Zyb2c_size_16_color_FFFFFF_t_70]: /images/20220114/e9a348d90df546ba97df55f76824bfe8.png
[20190614170214738.PNG]: /images/20220114/ba8fd3e340ab4d73bbe94670d2cd7c97.png