不妨借一步说话，你想知道的关于设计模式的种种

可以点击关于我联系我获取完整PDF
(VX：mm14525201314)

1. 请列举出在 JDK 中几个常用的设计模式？

单例模式（Singleton pattern）用于 Runtime，Calendar 和其他的一些类中。

工厂模式（Factory pattern）被用于各种不可变的类如 Boolean，像 Boolean.valueOf，

观察者模式（Observer pattern）被用于 Swing 和很多的事件监听中。

装饰器设计模式（Decorator design pattern）被用于多个 Java IO 类中。

2. 什么是设计模式？你是否在你的代码里面使用过任何设计模式？

设计模式是世界上各种各样程序员用来解决特定设计问题的尝试和测试的方法。设计模式是代码可用性的延伸

3.Java 中什么叫单例设计模式？请用 Java 写出线程安全的单例模式

单例模式重点在于在整个系统上共享一些创建时较耗资源的对象。整个应用中只维护一个特定类实例，它被所有组件共同使用。Java.lang.Runtime 是单例模式的经典例子。从 Java5 开始你可以使用枚举（enum）来实现线程安全的单例。

4. 在 Java 中，什么叫观察者设计模式（observer design pattern ）？

观察者模式是基于对象的状态变化和观察者的通讯，以便他们作出相应的操作。简单的例子就是一个天气系统，当天气变化时必须在展示给公众的视图中进行反映。这个视图对象是一个主体，而不同的视图是观察者

5.使用工厂模式最主要的好处是什么？在哪使用？

工厂模式的最大好处是增加了创建对象时的封装层次。如果你使用工厂来创建对象，之后你可以使用更高级和更高性能的实现来替换原始的产品实现或类，这不需要在调用层做任何修改。

6. 举一个用 Java 实现的装饰模式(decorator design pattern) ？它是作用于对象层次还是类层次？

装饰模式增加强了单个对象的能力。Java IO 到处都使用了装饰模式，典型例子就是Buffered 系列类如 BufferedReader 和 BufferedWriter，它们增强了 Reader 和 Writer 对象，以实现提升性能的 Buffer 层次的读取和写入。

7. 在 Java 中，为什么不允许从静态方法中访问非静态变量？

Java 中不能从静态上下文访问非静态数据只是因为非静态变量是跟具体的对象实例关联的，而静态的却没有和任何实例关联。

8. 设计一个 ATM 机，请说出你的设计思路？

比如设计金融系统来说，必须知道它们应该在任何情况下都能够正常工作。不管是断电还是其他情况，ATM 应该保持正确的状态（事务） , 想想加锁（locking）、事务（transaction）、错误条件（error condition）、边界条件（boundary condition）等等。尽管你不能想到具体的设计，但如果你可以指出非功能性需求，提出一些问题，想到关于边界条件，这些都会是很好的。

9. 在 Java中，什么时候用重载，什么时候用重写

如果你看到一个类的不同实现有着不同的方式来做同一件事，那么就应该用重写（overriding），而重载（overloading）是用不同的输入做同一件事。在 Java 中，重载的方法签名不同，而重写并不是。

10. 举例说明什么情况下会更倾向于使用抽象类而不是接口？

接口和抽象类都遵循”面向接口而不是实现编码”设计原则，它可以增加代码的灵活性，可以适应不断变化的需求。下面有几个点可以帮助你回答这个问题：

在 Java 中，你只能继承一个类，但可以实现多个接口。所以一旦你继承了一个类，你就失去了继承其他类的机会了。

接口通常被用来表示附属描述或行为如：Runnable丶Clonable、Serializable 等等，因此当你使用抽象类来表示行为时，你的类就不能同时是 Runnable 和 Clonable(注：这里的意思是指如果把 Runnable 等实现为抽象类的情况)，因为在 Java 中你不能继承两个类，但当你使用接口时，你的类就可以同时拥有多个不同的行为。在一些对时间要求比较高的应用中，倾向于使用抽象类，它会比接口稍快一点。如果希望把一系列行为都规范在类继承层次内，并且可以更好地在同一个地方进行编码，那么抽象类是一个更好的选择。有时，接口和抽象类可以一起使用，接口中定义函数，而在抽象类中定义默认的实现。

11.你所知道的设计模式有哪些？

创建型模式，共五种： 工厂方法模式、抽象工厂模式、单例模
式、建造者模式、原型模式。
结构型模式，共七种： 适配器模式、装饰器模式、代理模式、
外观模式、桥接模式、组合模式、享元模式。
行为型模式，共十一种： 策略模式、模板方法模式、观察者模
式、迭代子模式、责任链模式、命令模式、备忘录模式、状态
模式、访问者模式、中介者模式、解释器模式。

12.谈谈 MVC、MVP 和 MVVM，好在哪里，不好在哪里？

MVC:

视图层(View) 对应于 xml 布局文件和 java 代码动态view 部分
控制层(Controller) MVC 中 Android 的控制层是由Activity 来承担的，Activity 本来主要是作为初始化页面，展示数据的操作，但是因为 XML 视图功能太弱，所以 Activity 既要负责视图的显示又要加入控制逻辑，承担的功能过多。
模型层(Model) 针对业务模型，建立数据结构和相关的类，它主要负责网络请求，数据库处理，I/O 的操作。

总结

具有一定的分层，model 彻底解耦，controller 和 view并没有解耦层与层之间的交互尽量使用回调或者去使用消息机制去完成，尽量避免直接持有 controller 和view 在 android 中无法做到彻底分离，但在代码逻辑层面一定要分清业务逻辑被放置在 model 层，能够更好的复用和修改增加业务。

MVP

通过引入接口 BaseView，让相应的视图组件如Activity，Fragment 去实现 BaseView，实现了视图层的独立，通过中间层 Preseter 实现了 Model 和 View的完全解耦。MVP 彻底解决了 MVC 中 View和Controller 傻傻分不清楚的问题，但是随着业务逻辑的增加，一个页面可能会非常复杂，UI 的改变是非常多，会有非常多的 case，这样就会造成 View 的接口会很庞大。

MVVM

MVP 中我们说过随着业务逻辑的增加，UI 的改变多的情况下，会有非常多的跟 UI 相关的 case，这样就会造成 View 的接口会很庞大。而 MVVM 就解决了这个问题，通过双向绑定的机制，实现数据和 UI 内容，只要想改其中一方，另一方都能够及时更新的一种设计理念，这样就省去了很多在 View 层中写很多 case 的情况，只需要改变数据就行。

三者如何选择？

如果项目简单，没什么复杂性，未来改动也不大的话，那就不要用设计模式或者架构方法，只需要将每个模块封装好，方便调用即可，不要为了使用设计模式或架构方法而使用。
对于偏向展示型的 app，绝大多数业务逻辑都在后端，app 主要功能就是展示数据，交互等，建议使用mvvm。
对于工具类或者需要写很多业务逻辑 app，使用 mvp或者 mvvm 都可。

13.封装 p 层之后.如果 p 层数据过大,如何解决?

对于 MVP 模式来说，P 层如果数据逻辑过于臃肿，建议引入RxJava 或则 Dagger，越是复杂的逻辑，越能体现 RxJava 的优越性

14.是否能从 Android 中举几个例子说说用到了什么设计模式？

AlertDialog、Notification 源码中使用了 Builder（建造者）模式完成参数的初始化
Okhttp 内部使用了责任链模式来完成每个 Interceptor 拦截器的调用
自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数初中级Android工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则近万的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年Android移动开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。