• OC中的抽象基类 和 接口


      OC中没有抽象基类和接口的存在,而是使用的协议。作为C面向对象化的语言,肯定具备OOP的绝大多数的卖点。

      先说说抽象基类和接口,两者不同,我采访的一些其它语言的码农,他们给出的答案是,现代编程语言基本不怎么使用抽象基类,都是接口。嗯,得出的结论就是他们菜,忘掉刚才的答案。

      让我们以更专业的姿势,来深入探讨下两者。

      抽象基类(Abstract Class),俗称ABC。接口(Interface),俗称也是接口。两者都实现了OO中的继承机制。也都是通过定义抽象方法去实现对继承类功能上的约束。

      抽象基类可以为部分方法提供默认的实现,可以定义字段属性,从而避免子类的重复实现,可提高代码的可重用性,这是抽象类的优势;而接口只能包含抽象方法。

      何时使用抽象基类何时使用接口关键还是取决于待继承之间的联系。侧重于它们之间的个性差异还是共性联系。

      当个性大于共性。差异较大的个性间具有某些相同的行为,相同行为的实现方式有较大的区别,使用接口。

      当共性大于个性,共性相同的个体间必然具备相同的属性与行为,相同行为的实现方式具有一定区别,使用抽象基类。

      总结如下:

      当在差异较大的对象间寻求功能上的共性时,使用接口。 
      当在共性较多的对象间寻求功能上的差异时,使用抽象基类。

      以上专业术语,我抢来的.....

      在OC中,只提供了协议,然后,本文的重点则是,怎么去构建上面说的那些,接口的话,在OC中等同协议就好了,当然OC中的协议不是必须都要实现的,还有一些协议在运行时添加成员变量,直接在协议中添加属性,为的就是想要getter setter方法。都不在讨论的范围内。

      有关协议的使用,这里扩充一下,很多iOSer,只有在用代理(原谅我没用委托模式这四个字眼,如此甚屌的能把上帝类修理成框架类的设计模式,硬生生被很多人用到了反向传值上,还理直气壮的说原理就是a做不了某事,让b代理a去做。我去他妹的)反向传值的时候才会使用。

      有以下例子,假如有人、鱼、青蛙三个对象。每个对应的类,都有个游泳的方法。再有个数组,里面放着前面的三个类。数组内的对象数量、顺序不限。

      要求就是遍历这个数组,得到人的对象,就调用人游泳的方法。得到鱼的对象,调用鱼游泳的方法,等等。

      好吧,然后你就去看代码。首先for内得到一个对象,然后一口气上来了三个if,去判断这个对象属于哪个类型,再然后调用相应的游泳方法。如果对象的类型扩充到10个、100个,然后就可以看到很壮观的二三百行的if代码。真是爽上天的节奏,复制黏贴也要不少时间吧。

      回归刚才的透剧,协议的扩充,至于为什么没用抽象基类,看上面的总结,和下面举例子时对象之间的联系。

      创建一个游泳的协议,并且提供一个游泳的方法(抽象方法),分别让人、鱼、青蛙三个类遵守这个协议,并且实现游泳的方法。在遍历数组的时候声明一个id类型并且遵守这个协议的变量指向得到对象,而不用去判断对象类型,直接调用游泳的方法。

      oop的继承、封装、多态。大多都是知道,用的时候并不多,蛋疼的事,以上就是不算扩充的扩充。多是在处理mvc中的view时用到,比如有两三种cell的时候等等。

      然后再说 抽象基类。

      OC中 定义一个类,继承某个协议。此类用作基类。就能当抽象基类使用。(其实,直接一个基类,然后让子类分别重写对应的方法也能解决。毕竟接口就是很特殊的抽象基类)

      同样上例子

      鲤鱼、鲫鱼、草鱼三种。也要游泳。对象之间的共性(都是鱼)大于个性(略微不同的游泳方式)。

      这里的游泳是直接基类提供还是使用协议,看个人爱好。鉴于继承开销很大,而平时从事的项目,也并不是特大,特封装,特面向对象思想。我使用协议。区别自然是有的。不多做学术上的讲解和争论。

      此例中 首先要有个基类,鱼的类。三种鱼都继承与鱼基类。然后基类遵守游泳协议。一切看起来很美好,和上面的例子也没什么区别。抽象基类的优势在对象的状态上,也就是俗称的属性、成员变量等。每个鱼都有鱼鳞,鱼尾。甚至每个鱼的子类对象都有的行为:呼吸。这时候,鱼鳞、鱼尾类似的属性,表示对象状态的这些都添加到基类 鱼 类里面。呼吸的方法同样也添加在基类里面。子类,自然也继承到了,提高了代码的复用性,而不是每个子类都添加属性和方法。

      扯了这么多,都是个人现阶段的理解,用途也仅限于纪录自己的学习历程和新手启蒙。

      面向对象的三大法宝,封装,继承,多态。上面的例子谈得多的也是用继承去实现多态。严格的来说,封装性的良好才最能体现面向对象的这一理念。继承刚好是破坏封装性的行为,因为基类内部对子类可见。

      后面会有OC版的设计模式系列文章,此文作为前传。

      在最后说些设计相关的

      优先使用组合而非继承!

      优先使用组合而非继承!!

      优先使用组合而非继承!!!

      重要的事说三遍。

  • 相关阅读:
    Loadrunner脚本自动关联和手动关联
    Linux常用命令大全
    linux软件的安装和卸载
    PL/SQL DEVELOPER执行计划的查看
    利用pl/sql执行计划评估SQL语句的性能简析
    LoadRunner监控Linux与Windows方法
    LR添加Windows和Linux压力机实战
    《JS设计模式笔记》 4,桥接模式
    《ES6基础教程》之 Call 方法和 Apply 方法
    《JS设计模式笔记》 3,观察者模式
  • 原文地址:https://www.cnblogs.com/liuguanlei/p/4861352.html
Copyright © 2020-2023  润新知