美文网首页
第三章 接口与API设计—第15条:用前缀避免命名空间冲突

第三章 接口与API设计—第15条:用前缀避免命名空间冲突

作者: CoderCurtis | 来源:发表于2017-04-12 10:58 被阅读0次

    我们在构建应用程序时,可能想将其中部分代码用于后续项目,也可能想把某些代码发布出来,供他人使用。即便现在还不想这么做,将来也总会有用到的时候。如果决定重用代码,那么我们在编写接口时就会将其设计成易于复用的形式。这需要用到Objective-C语言中常见的编程范式(paradigm),同时还需了解各种可能碰到的陷阱。
    近年来,开源社区与开源组件随着iOS开发而流行起来,所以我们经常会在开发自己的应用程序时使用他人所写的代码。与此同时,别人也会用到你的代码,所以,要把代码写的清晰一些,以便其他开发者能够迅速而方便地将其集成到他们的项目里。没准会有成千上万个应用程序使用你所写的程序库呢。


    Objective-C没有其他语言那种内置的命名空间(namespace)机制。鉴于此,我们在起名时要设法避免潜在的命名冲突,否则很容易就重名了。如果发生命名冲突(naming clash),那么应用程序的链接过程就会出错,因为其中出现了重复符号:

    duplicate symbol _OBJC_METACLASS_$_EOCTheClass in:
          build/something.o
          build/something_else.o
    duplicate symbol _OBJC_CLASS_$_EOCTheClass in:
          build/something.o
          build/something_else.o
    

    错误原因在于,应用程序中的两份代码都各自实现了名为EOCTheClass的类,这导致EOCTheClass所对应的类符号和"元类"符号各定义了两次。你也许是把两个相互独立的程序库都引入到当前项目中,而它们又恰好有重名的类,所以产生了这一问题。
    比无法链接更糟糕的情况是,在运行期载入了含有重名类的程序库。此时,"动态加载器"(dynamic loader)就遭遇了"重名符号错误"(duplicate symbol error),很可能会令整个应用程序崩溃。
    避免此问题的唯一办法就是变相实现命名空间: 为所有名称都加上适当前缀。所选前缀可以使公司、应用程序或二者皆有关联之名。比方说,假设你所在的公司叫做Effective Widgets,那么就可以在所有应用程序都会用到的那部分代码中使用EWS作前缀,如果有些代码只用于名为Effective Browser的浏览器项目中,那就在这部分代码中使用EWB作前缀。即便加了前缀,也难保不出现命名冲突,但是其几率会小很多。
    使用Cocoa创建应用程序时一定要注意,Apple宣称其保留使用所有"两字母前缀"(two-letter prefix)的权利,所以你自己选用的前缀应该是三个字母的。举个例子,假如开发者不遵循这条守则,使用TW这两个字母作前缀,那么就会出问题。iOS5.0 SDK发布时,包含了Twitter框架,此框架就使用TW作前缀,其中有个类叫做TWRequest,它可以发送HTTP请求以调用Twitter API。如果你所在的公司叫做Tiny Widgets,那么很有可能把访问本公司API所用的那个类也命名为TWRequest。
    不仅是命名,应用程序中的所有名称都应加前缀。如果要为既有类新增"分类"(category),那么一定要给"分类"及"分类"中的方法加上前缀,第25条解释了这么做的原因。开发者可能会忽视另外一个容易引发命名冲突的地方,那就是类的实现文件中所用的纯C函数及全局变量,这个问题必须要注意。大家可别忘了,在编译好的目标文件中,这些名称是要算作"顶级符号"(top-level symbol)的。比方说,iOS SDK的AudioToolbox里有个函数能播放声音文件。开发者可向其传入回调函数(callback),以便在播放完毕时调用。你也许想编写一个Objective-C类,把这套逻辑封装起来,当播放完声音文件之后,即命令其中的委托对象(delegate)处理回调事宜:

    //EOCSoundPlayer.h
    #import <Foundation/Foundation.h>
    
    @class EOCSoundPlayer;
    @protocol EOCSoundPlayerDelegate <NSObject>
    - (void)soundPlayerDidFinish:(EOCSoundPlayer *)player;
    @end
    
    @Interface EOCSoundPlayer : NSObject
    @property (nonatomic, weak) id <EOCSoundPlayerDelegate> delegate;
    - (id)initWithURL:(NSURL *)url;
    - (void)playSound;
    @end
    //EOCSoundPlayer.m
    #import "EOCSoundPlayer.h"
    #import <AudioToolbox/AudioToolbox.h>
    
    void completion (SystemSoundID ssID, void*clientData) {
          EOCSoundPlayer *player = (__bridge EOCSoundPlayer *)clientData;
          if ([player.delegate respondsToSelector:@selector(soundPlayerDidFinish:)]) {
                  [player.delegate soundPlayerDidFinish:player];
            }
    }
    
    @implementation EOCSoundPlayer {
          SystemSoundID _systemSoundID;
    }
    
    - (id)initWithURL:(NSURL *)url {
            if ((self = [super init])) {
                  AudioServicesCreateSystemSoundID((__bridge CFURLRef)url, &_systemSoundID);
            }
            return self;
    }
    
    - (void)dealloc {
     AudioServicesDisposeSystemSound(_systemSoundID);
    }
    
    - (void)playSound{
          AudioServicesAddSystemSoundCompletion {
                _systemSoundID,
                NULL,   
                NULL,
                completion,
                (__bridge void *)self;
      AudioServicesPlaySystemSound(_systemSoundID);
          }
          @end
    }
    

    这段代码看上去完全正常,不过你再看看该类目标文件中的符号表(symbol table),就会发现问题了:

    屏幕快照 2017-04-13 09.32.46.png

    符号表中间有个名叫_completion的符号,这就是为了处理声音播放完毕之后的逻辑而创建的那个completion函数。虽说此函数是在实现文件里定义的,并没有声明于头文件中,不过它仍然算作"顶级符号"。这样的话,若在别处又创建了一个名叫completion的函数,则会于链接时发生类似下面这种"重复符号错误":

    duplicate symbol _completion in:
            build/EOCSoundPlayer.o
            build/EOCAnotherClass.o
    

    如果将代码发布为程序库,供他人在开发应用程序时使用,那么就更糟糕了。这等于办了件坏事: 因为已经有了名叫_completion的符号,所以使用此程序库的开发者就无法再创建名为completion的函数了。

    由此可见,我们总是应该给这种C函数的名字加上前缀。比方说,在刚才那个例子中,播放完声音之后所执行的处理程序可以改名为EOCSoundPlayerCompletion。这么做还有个好处:若此符号出现在栈回溯信息中,则很容易就能判明问题源自哪块代码。
    如果用第三方库编写自己的代码,并准备将其再发布为程序库供他人开发应用程序所用,那么尤其要注意重复符号问题。你的程序库所包含的那个第三方库也许还会为应用程序本身所引入,若是如此,那就很容易出现重复符号错误了。这是应该给你所用的那一份第三方库代码都加上你自己的前缀。例如,你准备发布的程序库叫做EOCLibrary,其中引入了名为XYZLibrary的第三方库,那么就应该把XYZLibrary中的所有名字都冠以EOC。于是,应用程序就可以随意使用它自己直接引入的那个XYZLibrary库了,而不必担心与EOCLibrary里的这个XYZLibrary相冲突。
    虽说逐个改名是很令人厌烦的事情,不过若想避免命名冲突,还是得费这番功夫才行。读者也许会问: 为什么非要这么做呢?应用程序自己不要直接引入XYZLibrary,改用EOCLibrary里面的那个不就行了吗?没错,可以这么做,但是,应用程序也许还会引入另一个名为ABCLibrary的第三方库,而该库中又包含了XYZLibrary。此时,如果你和ABCLibrary库的作者都不给各自所用的XYZLibrary加前缀,那么应用程序依然会出现重复符号错误。还有一种可能就是,你的库里所用的XYZLibrary是X版本的,而应用程序却需要使用Y版本的某些功能,所以它必须自己再引入一份。你可以花些时间,使用几个流行的第三方库来开发一下iOS程序,那时会经常看到这种前缀的。

    要点

    • 选择与你的公司、应用程序或二者皆有关联之名称作类名的前缀,并在所有代码中均使用这一前缀。
    • 若自己所开发的程序库中用到了第三方库,则应为其中的名称加上前缀。

    相关文章

      网友评论

          本文标题:第三章 接口与API设计—第15条:用前缀避免命名空间冲突

          本文链接:https://www.haomeiwen.com/subject/vlsmattx.html