阅读 524

iOS开发架构(架构的七大原则、MVC架构模式、MVVM架构模式)

一、软件架构的原则


软件架构的七大原则如下:

1.开闭原则

2.依赖倒置原则

3.单一职责原则

4.接口隔离原则

5.迪米特法则(最小知道原则)

6.里氏替换原则

7.合成/聚合复用原则

8.图片描述

1.开闭原则

对扩展开放,对修改关闭。

说的是,在设计一个模块的时候,应当使这个模块可以在不被修改的前提下被扩展. 换言之,应当可以在不必修改源代码的情况下改变这个模块的行为,在保持系统一定稳定性的基础上,对系统进行扩展。 例如:一般软件功能的升级就需要符合开闭原则,即不去修改原来的代码,而是去增加新功能。

2. 依赖倒置原则

实现尽量依赖抽象,不依赖具体实现。

该原则有以下三点说明:

  • 1、高层模块不应该依赖于底层模块,两者都应该依赖于抽象。

  • 2、抽象不应该依赖于细节,即具体实现类。

  • 3、细节应该依赖于抽象。

这样带来的好处,可以减少类与类之间的耦合性,提高系统的稳定性,提高代码的可读性和可维护性,并且可以降低修改程序所造成的的风险。

这就是我们通常说的面向接口编程

3. 单一职责原则

对于一个类而言,应该仅存在一个可以引起类变化的原因。

这条原则从字面意思来说就是:一个类、接口、方法职责尽量单一。这样我们就能很好的进行解耦,后期的需求变更和维护不会互相受影响,能够降低类的复杂度,提高可读性。

4. 接口隔离原则

客户端不应该依赖它不需要的接口,类之间的依赖关系应该建立在最小的接口上。 这个原则指导我们在设计接口时应当注意以下几点:

  • 1、一个类对另一个类的依赖应该建立在最小的接口之上。
  • 2、建立单一接口,不要建立功能繁多的总接口。
  • 3、尽量细化接口,接口中的方法尽量少(不是越少越好,一定要适度)。

该原则符合高内聚低耦合的设计思想,可以使类具有很好的可读性、可扩展性和可维护性

5. 迪米特法则(最小知道原则)

一个对象应该对其他对象保持最少的了解,尽量降低类与类之间的耦合。

由于每个类尽量减少对其他类的依赖,因此,很容易使得系统的功能模块功能独立,相互之间不存在(或很少有)依赖关系。迪米特法则不希望类之间建立直接的联系。如果有真的需要建立联系的,也希望能通过他的友元类来转达。 迪米特原则主要强调只和朋友交流,不和陌生人说话。出现在成员变量、方法的输入、输出参数中的类都可以称之为成员朋友类,而出现在方法体内部的类不属于朋友类 。

6. 里氏替换原则

一个软件实体如果适用一个父类的话,那一定是适用于其子类,所有引用父类的地方必须能透明地使用其子类的对象,子类对象能够替换父类对象,而程序逻辑不变。

我们总结一下:子类可以扩展父类的功能,但不能改变父类原有的功能。

  • 1、子类可以实现父类的抽象方法,但不能覆盖父类的非抽象方法。
  • 2、子类中可以增加自己特有的方法。
  • 3、当子类的方法重载父类的方法时,方法的前置条件(即方法的输入/入参)要比父类方法的输入参数更宽松。
  • 4、当子类的方法实现父类的方法时(重写/重载或实现抽象方法),方法的后置条件(即方法的输出/返回值)要比父类更严格或相等。

使用里氏替换原则有以下优点:

  • 1、约束继承泛滥,开闭原则的一种体现。
  • 2、加强程序的健壮性,同时变更时也可以做到非常好的兼容性,提高程序的维护性、扩展性。降低需求变更时引入的风险 。

7. 合成/聚合复用原则

尽量使用对象组合(has-a)/聚合(contanis-a),而不是继承关系达到软件复用的目的。

换句话说,就是在一个新的对象里面使用一些已有的对象,使之成为新对象的一部分,新的对象通过这些对象的委派达到复用已有功能的目的。

该原则可以使系统更加灵活,降低类与类之间的耦合度,一个类的变化对其他类造成的影响相对较少。

二、MVC架构


MVCModel-View-Controller 的简写。MVC主要有三层:

  • Model:数据层,读写数据,保存 App 状态。
  • View:页面层,和用户交互,向用户显示页面,反馈用户行为。
  • ViewController: 逻辑层,更新数据,或者页面,处理业务逻辑。

MVC可以帮助你很好的将数据,页面,逻辑的代码分离开来。使得每一层相对独立。这样你就能够将一些可复用的功能抽离出来,化繁为简。只不过,一旦 App 的交互变复杂,你就会发现 ViewController 将变得十分臃肿。大量代码被添加到控制器中,使得控制器负担过重

此处特别说明:如果只是为了解决VC中代码臃肿的短板,把VC中的逻辑代码按功能模块使用分类(category)进行拆分,只保留必要的调用接口能有效的降低VC中代码臃肿的问题。

三、MVVM架构


MVVMModel-View-ViewModel的简写,是由MVP(Model-View-Presenter)模式与WPF结合的应用方式时发展演变过来的一种新型架构框架。

MVVM层架结果如下:

  • Model: 数据层,读写数据,保存 App 状态。
  • View:页面层,提供用户输入行为,并且显示输出状态。
  • ViewModel 逻辑层,它将用户输入行为,转换成输出状态。
  • ViewController:主要负责数据绑定。

这里其实叫MVVM-C架构更合适。

ViewModel 是逻辑层,而控制器只需要负责数据绑定。如此一来控制器的负担就减轻了许多。并且ViewModel与控制器以及页面相独立。那么,你就可以跨平台使用它。你也可以很容易地测试它。

MVVM模式使用的是数据绑定基础架构,这是MVVM设计模式的核心,在使用中,利用双向绑定技术,使得 Model 变化时,ViewModel 会自动更新,而 ViewModel 变化时,View 也会自动变化。ViewModel包含所有由UI特定的接口和属性,并有一个 ViewModel 的视图的绑定属性,当绑定的属性变化时,View会自动更新视图,所以可以把更新视图的逻辑放到ViewModel中,减少了Controller的代码,iOS实现这种绑定可以使用 通知 和 KVO

ViewModel其实相当于一个黑盒子,接收输入,经过内部业务逻辑处理产出结果。

四、 总结


本文主要介绍了软件架构的七大原则、MVC架构模式、MVVM架构模式。

不管我们选择何种架构模式,我们都是朝着代码的可扩展性、可维护性、复用性、可读性去的。我们最终的目的都是为了降低代码的耦合性,方便后续的修改、扩展和维护。

MVVM模式MVC模式最大的特点并不是降低了VC中代码的臃肿,而是MVMM架构模式把业务逻辑统一到了VM中处理,方便单元测试和自动化测试。

我们在实际开发中一定要根据我们的实际情况来选择架构模式,不要一味地追新,适合自己当下业务的架构模式才是好的架构模式,不要画虎不成反类犬。

以上只是个人见解,如有不同见解,还望不吝赐教。

咱们有一个大型“iOS开发同性”交流群:679884541 !有问题可以在群里一起交流,群里还有群主精心准备的最新面试题合集和进阶学习资料,欢迎你的加入!

关注下面的标签,发现更多相似文章
评论