之前有位读者私信问我,在之前的面试中面试官突然问道了关于设计模式的种种,还有设计模式相关的设计到的知识,自己回答的不是特别完美,问问有没有相关的整理
那么今天我们着重分析下设计模式,以及设计模式的种种面试专题
下面的所有的种种都在我整理的983页PDF里面了,含有BATJ.字节跳动面试专题,算法专题,高端技术专题,混合开发专题,java面试专题,Android,Java小知识,到性能优化.线程.View.OpenCV.NDK等应有尽有。还有辅之相关的视频+学习笔记
(更多完整项目下载。未完待续。源码。图文知识后续上传github。)
可以点击关于我联系我获取完整PDF
(VX:mm14525201314)
单例模式(Singleton pattern)用于 Runtime
,Calendar 和其他的一些类中。
工厂模式(Factory pattern)被用于各种不可变的类如 Boolean,像 Boolean.valueOf
,
观察者模式(Observer pattern)被用于 Swing 和很多的事件监听中。
装饰器设计模式(Decorator design pattern)被用于多个 Java IO 类中。
设计模式是世界上各种各样程序员用来解决特定设计问题的尝试和测试的方法。设计模式是代码可用性的延伸
单例模式重点在于在整个系统上共享一些创建时较耗资源的对象。整个应用中只维护一个特定类实例,它被所有组件共同使用。Java.lang.Runtime
是单例模式的经典例子。从 Java5 开始你可以使用枚举(enum
)来实现线程安全的单例。
观察者模式是基于对象的状态变化和观察者的通讯,以便他们作出相应的操作。简单的例子就是一个天气系统,当天气变化时必须在展示给公众的视图中进行反映。这个视图对象是一个主体,而不同的视图是观察者
工厂模式的最大好处是增加了创建对象时的封装层次。如果你使用工厂来创建对象,之后你可以使用更高级和更高性能的实现来替换原始的产品实现或类,这不需要在调用层做任何修改。
装饰模式增加强了单个对象的能力。Java IO 到处都使用了装饰模式,典型例子就是Buffered 系列类如 BufferedReader
和 BufferedWriter
,它们增强了 Reader 和 Writer 对象,以实现提升性能的 Buffer 层次的读取和写入。
Java 中不能从静态上下文访问非静态数据只是因为非静态变量是跟具体的对象实例关联的,而静态的却没有和任何实例关联。
比如设计金融系统来说,必须知道它们应该在任何情况下都能够正常工作。不管是断电还是其他情况,ATM 应该保持正确的状态(事务) , 想想 加锁(locking)、事务(transaction)、错误条件(error condition)、边界条件(boundary condition) 等等。尽管你不能想到具体的设计,但如果你可以指出非功能性需求,提出一些问题,想到关于边界条件,这些都会是很好的。
如果你看到一个类的不同实现有着不同的方式来做同一件事,那么就应该用重写(overriding),而重载(overloading)是用不同的输入做同一件事。在 Java 中,重载的方法签名不同,而重写并不是。
接口和抽象类都遵循”面向接口而不是实现编码”设计原则,它可以增加代码的灵活性,可以适应不断变化的需求。下面有几个点可以帮助你回答这个问题:
在 Java 中,你只能继承一个类,但可以实现多个接口。所以一旦你继承了一个类,你就失去了继承其他类的机会了。
接口通常被用来表示附属描述或行为如:Runnable
丶Clonable
、Serializable
等等,因此当你使用抽象类来表示行为时,你的类就不能同时是 Runnable
和 Clonable
(注:这里的意思是指如果把 Runnable
等实现为抽象类的情况),因为在 Java 中你不能继承两个类,但当你使用接口时,你的类就可以同时拥有多个不同的行为。在一些对时间要求比较高的应用中,倾向于使用抽象类,它会比接口稍快一点。如果希望把一系列行为都规范在类继承层次内,并且可以更好地在同一个地方进行编码,那么抽象类是一个更好的选择。有时,接口和抽象类可以一起使用,接口中定义函数,而在抽象类中定义默认的实现。
xml
布局文件和 java 代码动态view 部分MVC
中 Android 的控制层是由Activity 来承担的,Activity 本来主要是作为初始化页面,展示数据的操作,但是因为 XML 视图功能太弱,所以 Activity 既要负责视图的显示又要加入控制逻辑,承担的功能过多。具有一定的分层,model 彻底解耦,controller 和 view并没有解耦层与层之间的交互尽量使用回调或者去使用消息机制去完成,尽量避免直接持有 controller 和view 在 android 中无法做到彻底分离,但在代码逻辑层面一定要分清业务逻辑被放置在 model 层,能够更好的复用和修改增加业务。
通过引入接口 BaseView
,让相应的视图组件如Activity,Fragment 去实现 BaseView
,实现了视图层的独立,通过中间层 Preseter
实现了 Model 和 View的完全解耦。MVP 彻底解决了 MVC 中 View和Controller 傻傻分不清楚的问题,但是随着业务逻辑的增加,一个页面可能会非常复杂,UI 的改变是非常多,会有非常多的 case,这样就会造成 View 的接口会很庞大。
MVP 中我们说过随着业务逻辑的增加,UI 的改变多的情况下,会有非常多的跟 UI 相关的 case,这样就会造成 View 的接口会很庞大。而 MVVM 就解决了这个问题,通过双向绑定的机制,实现数据和 UI 内容,只要想改其中一方,另一方都能够及时更新的一种设计理念,这样就省去了很多在 View 层中写很多 case 的情况,只需要改变数据就行。
对于 MVP 模式来说,P 层如果数据逻辑过于臃肿,建议引入RxJava
或则 Dagger,越是复杂的逻辑,越能体现 RxJava
的优越性
AlertDialog
、Notification
源码中使用了 Builder(建造者)模式完成参数的初始化Okhttp
内部使用了责任链模式来完成每个 Interceptor 拦截器的调用RxJava
的观察者模式;单例模式;GridView
的适配器式;Intent 的原型模式BaseActivity
抽象工厂模式两者都是对类的方法进行扩展,但装饰器模式强调的是增强自身,在被装饰之后你能够在被增强的类上使用增强后的功能。
单例模式实现方法有多种: 饿汉,懒汉(线程安全,线程非安全),双重检查(DCL),内部类,以及枚举
面试常客: Okhttp,Retrofit,Glide,RxJava,GreenDao,Dagger 等
请查看完整的PDF版
(更多完整项目下载。未完待续。源码。图文知识后续上传github。)
可以点击关于我联系我获取完整PDF
(VX:mm14525201314)
原文:https://blog.51cto.com/14541311/2454486