⑨ 设计模式相关面试题
⑨ 设计模式相关面试题
一.编程中的六大设计原则？
1.单一职责原则
通俗地讲就是一个类只做一件事
-
CALayer：动画和视图的显示。 -
UIView：只负责事件传递、事件响应。
2.开闭原则
对修改关闭，对扩展开放。
要考虑到后续的扩展性，而不是在原有的基础上来回修改
3.接口隔离原则
使用多个专门的协议、而不是一个庞大臃肿的协议
UITableviewDelegateUITableViewDataSource
4.依赖倒置原则
抽象不应该依赖于具体实现、具体实现可以依赖于抽象。
调用接口感觉不到内部是如何操作的
5.里氏替换原则
父类可以被子类无缝替换，且原有的功能不受任何影响
例如 KVO
6.迪米特法则
一个对象应当对其他对象尽可能少的了解，实现高聚合、低耦合
推荐文章
面向对象设计的六大设计原则（附 Demo 及 UML 类图）- J_Knight_
二.如何设计一个图片缓存框架？
可以模仿 SDWebImage 来实现。
构成
- Manager
- 内存缓存
- 磁盘缓存
- 网络下载
- Code Manager
- 图片解码
- 图片解压缩
图片的存储是以图片的单向 hash 值为 Key
内存设计需要考虑的问题
存储的 Size
因为内存的空间有限，我们针对不同尺寸的图片，给出不同的方案
-
10K以下的50个 -
100Kb以下的20个 -
1000kb以上的10个
淘汰的策略
内存的淘汰策略 采取 LRU（最近最少使用算法）
触发淘汰策略的时机有三种
- 1.定期检查（不建议，耗性能）
- 2.提高检查触发频率（一定要注意开销）
- 1.前后台切换的时候
- 2.每次读写的时候
磁盘设计需要考虑的问题
-
存储方式
-
大小限制（有固定的大小）
-
移除策略（可以设置为7天或者15天）
网络设计需要考虑的问题
-
图片请求的最大并发量
-
请求超时策略
-
请求优先级
图片解码
应用 策略模式，针对 jpg、png、gif 等不同的图片格式进行解码
图片解码的时机
- 在 子线程 图片刚下载完时
- 在 子线程 刚从磁盘读取完时
避免在主线程解压缩、解码，避免卡顿
三.如何设计一个时长统计框架？
记录器
- 页面式记录器
- 流式记录器
- 自定义式
记录管理者
- 内存记录缓存
- 磁盘存储
- 上传器
如何降低数据的丢失率？
- 定期写入磁盘
- 每当达到某个值的时候，就写入磁盘
记录上传的时机
- 前后台切换的时候可以上传
- 从无网到有网切换的时候可以上传
上传时机的选择
- 立即上传
- 定时上传
- 延时上传
四.如何实现 App 换肤（夜间模式）？
扩利用 DKNightVersion 完成。
同时可以参考一下这篇文章。
五.iOS有哪些常见的设计模式?
-
代理模式
应用场景：当一个类的某些功能需要由别的类来实现，但是又不确定具体会是哪个类实现。
优势：解耦合
敏捷原则：开放-封闭原则 -
观察者模式
应用场景：一般为model层对controller和view进行的通知方式，不关心谁去接收，只负责发布信息。
优势：解耦合
敏捷原则：接口隔离原则，开放-封闭原则 -
MVC模式
应用场景：是一种非常古老的设计模式，通过数据模型，控制器逻辑，视图展示将应用程序进行逻辑划分。
优势：使系统，层次清晰，职责分明，易于维护
敏捷原则：对扩展开放-对修改封闭 -
单例模式
应用场景：确保程序运行期某个类，只有一份实例，用于进行资源共享控制。
优势：使用简单，延时求值，易于跨模块
敏捷原则：单一职责原则 -
策略模式
应用场景：定义算法族，封装起来，使他们之间可以相互替换。
优势：使算法的变化独立于使用算法的用户
敏捷原则：接口隔离原则；多用组合，少用继承；针对接口编程，而非实现。 -
工厂模式
应用场景：工厂方式创建类的实例，多与proxy模式配合，创建可替换代理类。
优势：易于替换，面向抽象编程，application只与抽象工厂和易变类的共性抽象类发生调用关系。
敏捷原则：DIP依赖倒置原则
六.单例会有什么弊端？
-
主要优点：
- 1、提供了对唯一实例的受控访问。
- 2、由于在系统内存中只存在一个对象，因此可以节约系统资源，对于一些需要频繁创建和销毁的对象单例模式无疑可以提高系统的性能。
- 3、允许可变数目的实例。
-
主要缺点：
- 1、由于单利模式中没有抽象层，因此单例类的扩展有很大的困难。
- 2、单例类的职责过重，在一定程度上违背了“单一职责原则”。
- 3、滥用单例将带来一些负面问题，如为了节省资源将数据库连接池对象设计为的单例类，可能会导致共享连接池对象的程序过多而出现连接池溢出；如果实例化的对象长时间不被利用，系统会认为是垃圾而被回收，这将导致对象状态的丢失。
