Objective-CとSwiftのクラス定義の落とし穴

注意: この記事は1年以上前に掲載されたものです。情報が古い場合がありますのでお気を付け下さい。

SwiftがObjective-Cの後継という位置付けという関係からか、Objective-CとSwiftは1対1で対応していると思われがちだが、実際にはそういうわけではなく、落とし穴となるようなところはたくさんある。ここで説明するクラス定義も同様で、Objective-CとSwiftでは気をつけなければならない場合がある。

Objective-Cにおいては、別のフレームワークを使っていない限りは、基本的に独自に定義するクラスはNSObjectのサブクラスという位置付けである ((UIViewやUIViewControllerなどもNSObjectのサブクラスである。例外としてはサードパーティーのフレームワークを使用している場合、またはNSProxyのサブクラスとしている場合。前者はかなり特殊な例、後者も使用するケースはそれほど多くない)) 。したがって、基本的には最低限NSObjectの挙動をすると言っても問題ないものだろう。基本的にObjective-Cにおいては、NSObjectがベースになっているという構造になっている。

一方、Swiftではそうとは限らない。以下のような書き方も考えられる。

class Hoge {
    // any code...
}

この場合は、NSObjectのサブクラスではなく、Swiftのネイティブクラスとして扱われる。したがって、Objective-Cと連携させるなどで、NSObject系のプロトコルを実装するクラスを定義したい時は、NSObjectのサブクラスにする必要がある。例えば以下のようにである。

class Hoge : NSObject, AnyProtocol {
    // any code
}

このような落とし穴もあるので、Objective-CからSwiftへ乗り換える、あるいは混在させる際にはこれらのような注意点にも気をつける必要があることは念頭に入れたほうが良いだろう。

タイトルとURLをコピーしました