基于面向对象的设计模式

工作之余总结以下常见的设计模式, 由于工作较忙, 有时间就会添加, 敬请谅解, 希望对您有所帮助, 如果您发现其中有误, 可留言喷涂, 小弟在此谢过☻☻☻

一、观察者设计模式

• 观察者设计模式:
  • 当我们程序中的多个业务模块依赖同一个接口的数据的时候, 我们就可以使用观察者模式来解决这个问题; 其中被依赖的对象一般称为Subject, 依赖对象称为Observer, 当某个Observer想依赖Subject的数据的时候, 就调用Subject的注册方法, 当Subject的数据出现变化的时候, 就直接通过某种方式通知Observer, Observer就接收到响应的数据;
• 实现:
  • 我们可以通过自己抽象接口的方式来自己实现;
  • 也可以通过Java自带的类Observable(我们所说的接口Subject), 和接口Observer来实现;
• ☞ 在通知之前先要设置一个标记setChanged来标记这次的数据更新是需要通知的;

二、策略设计模式

• 问题:
  • 当我们要观察并总结某些类之间的关系的时候会发现，如果类之间都使用（当然,它们之间可以有继承的前提下）继承来实现，那么结果会让我们的整个框架体系变得非常不可控，比如，我有一个Animal的类，Animal下面有禽类，哺乳类，鸟类等，如果现在业务中有飞这么一种需求, 不是所有的禽类都不会飞, 也不是所有的鸟类都会飞, 那试问, 我们把飞这个方法放在Animal中, 行吗?
• 方案:
  • 对于上面的问题: 行, 在Animal中定义飞的方法, 在会飞的鸟类的对应类中重写飞的方法, 在会飞的禽类对应的类中实现飞的方法; 不行!!!存在一个问题, 我们把飞的方法放在了Animal中, 那么所有的子类都可以重写这个方法, 即所有的子类都可能飞, 这个问题就严重了, 猪都会飞了...
  • 把飞的方法定义在一个接口上, 让会飞的动物实现这个接口, 那么这个会飞的动物就必须实现这个接口, 也就有了飞的方(gong)法(neng);
• 质疑:
  • 有的同学肯定会说, 小二, 不对丫, 你怎么能规定那些鸟能飞, 哪些鸟不能飞啊, 我也可以让猪也实现这个方法, 那猪不也飞起来了吗? 大家想, 如果我定义一个接口:IFlyable, 其中有一个抽象方法: fly, 当我们需要调用某个类的fly方法的时候是不是先要判断这个类是不是instanceof这个借口? 必须的, 如果你不判断, 对不起, 就等着程序给你发脾气吧☻☻☻...
• 策略设计模式
  • 类A持有接口类型(基于多态)的成员变量, 在类A的方法中使用上面的接口类型变量调用这个接口的方法, 在任何类(包括子类)中只要实现这个接口, 那么就能调用父类的这个方法;
• 本质:
  • 策略设计模式的本质就是子类的方法不便统一的前提下, 我们就可以使用接口的方式来规定哪些类必须实现哪些接口, 进而实现其中的方法;
  • 这个模式让逻辑的控制独立于个体差异;
  • 这个模式是模块组件化的一种实现方式;
  • 这个模式基于接口实现;