设计模式六大原则:
单一指责原则:就是一个类而言,应该仅有一个引起它变化的原因(解耦,减少职责耦合)
开放封闭原则:类,模块,函数等应该可以拓展的,但不可修改(增加一个抽象的功能)
里氏替换原则:所有引用父类的地方必须要透明底使用其子类的对象(里氏替换原则是实现开放封闭原则的重要方式之一)
依赖倒置原则:高层模块不应该一来底层模块,两者都应该依赖于抽象。抽象不应该依赖于细节,细节应该依赖于抽象
迪米特原则(最少知识原则):一个软件实体应当尽可能少地与其他实体发生相互作用
接口隔离原则:一个类对另一个类的依赖应该建立在最小的接口上
创建型设计模式,共5种:单例模式,工厂方法模式,抽象工厂模式,建造者模式,原型模式
结构型设计模式,共7种:适配器模式,装饰模式,代理模式,外观模式,桥接模式,组合模式,享元模式
行为型设计模式,共11种:策略模式,模板方法模式,观察者模式,迭代器模式,责任链模式,命令模式,备忘录式,状态模式,访问者模式,中介者模式,解释器模式。
单例模式是最常用,最基础的设计模式,它主要用于避免创建重复的对象。全局最多有且只有一个实例。
面试也常有手撕设计模式,而单例模式出场率高达90+%,所以这时候把下面这段代码丢给面试官就好了
public class Singleton{
//静态变量实例
private static Singleton instance;
//私有化构造函数,避免外部实例化
private Singleton(){}
//同步实例,如果实例为空则创建,否则直接返回缓存的实例即可
public synchronized static Singleton getInstance(){
if(instance == null) instance = new Singleton();
return instance;
}
}
如果你实在想不起上面的代码(最好撸多几次),那么kotlin将给你带来福利
object Singleton{}
是的,就是这样。写完了。(OMG,有没有爱上kotlin?)
如果面试的时候,有可能还会问你一些你使用过的场景,或者见过的单例模式。(如果没有问,也可以说说自己遇到过的单例模式)
我谈谈个人经历:我们通常会设计一个类继承Applicaiton,作为app的程序入口,处理一些事务。其实这个也是一个单例模式;还有自己写过的一个ActivityManager,用来管理所有的Activity;EventBus中也出现了单例模式的使用,它内部缓存了各个组件发送过来的event对象,并负责分发出去,各个组件需要向同一个EventBus注册自己,才能接收到event事件,肯定是需要全局唯一的对象,所以采用了单例模式。
ActivityManager
/**
* @author Quincy
* @Date 2020/3/19
* @Description Activity管理类
*/
public class ActivityManager {
private List activities = new ArrayList();
private static ActivityManager instance;
private ActivityManager() {
}
public synchronized static ActivityManager getInstance() {
if (null == instance) {
instance = new ActivityManager();
}
return instance;
}
//在Activity基类的onCreate()方法中执行
public void addActivity(Activity activity) {
activities.add(activity);
}
//注销是销毁所有的Activity
public void OutSign() {
for (Activity activity : activities) {
if (activity != null) {
activity.finish();
}
}
}
}
今天是撸《第一行代码》(第三版)的第一天,其实在17年的时候,已经撸过一遍kotlin的基本知识点,当时觉得什么鬼啊,反人类的设计,可读性好差。However,
PS: 秉持着联机学习 1+1>2的原则,欢迎大家指点批评,互相交流学习~