iOSプログラミングのキモ(行き当たりばったりなプログラミングでも、何とか形にするために守っていることその１)

公開日： 2014/05/13 : Computer Language, FileQ, iOS, iPhone, Java, MacOS X, Objective-C, XCode, オブジェクト指向プログラミング, プログラミング

FileQ iOS版がリリースされて、のんびりしたい気持ちもありますが、FileQ Android版の準備を始めています(^_^)

今回のテーマですが、FileQ iOS版も、QTubeも私が一人で開発したこともありますが、システム開発で言うところの基本設計、詳細設計といった作業はせず割りと思いつくままにコードを書きました。

行き当たりばったりなので、途中でコードはどんどん変わっていきます。ボタン1つ押したその後のアクションだけでも最初は１つだけだと思っても後から２つ３つとやらせたい機能が増えることはしょっちゅうです。画面もどんどん増えます。その中で最初は必要だと思って作ったクラスがその後必要なくなることもあります。機能追加・変更作業はリファクタリングの連続みたいなものです。

システム開発では、開発途中に仕様追加・変更がよく起こります。
開発側から見ると出来るだけやめて欲しい(笑)ところですが、どうしても対応しなければいけないこともよくあります。

WEB系のシステムでは最近では何かしらのフレームワークを使いながら開発を進めることが多いので、その枠(フレーム)から外れない
追加・変更であれば割りと対応しやすくなってきました。

アプリ開発の場合は WEB系のシステム開発ほど枠（フレーム）がある状態ではありません。
これはアプリよって設計も異なることが多いので１つの枠組(フレームワーク)ではカバー出来ないということも起因している気がします。

とは言え、アプリも仕様追加・変更がよく起こることに変わりはないので何とか上手く対応して行くことが求められます
ということで今回は私が、行き当たりばったり（急な仕様追加・変更）なやり方でもアプリとして形にするために守っている手法を紹介します。

今回はデザインパターンで紹介されている手法に照らし合わせながら、説明していきます。

1，Singleton デザインパターンを積極的に使う

Singletonデザインパターンは、システムがランタイム時にインスタンスが１つだけしかないことを保証するデザインパターンです。

なんのこっちゃ(笑)って感じですが、WEBシステムでもアプリでもシングルトンにすることで、システムの全体像の見通しが良くなることがあります。

JavaではDIコンテナ（SpringやSeasar2）が2000年代中頃以降積極的に使われています。

DIコンテナに登録したクラスは基本的にシングルトンとして扱われます、またアブストラクトファクトリーデザインパターンやアスペクト指向プログラミングも同時に提供しているので、クラス生成の管理や機能追加・変更に一貫した手法が提供されるので品質が一定しやすいというメリットもあります。

私は、親子関係にないインスタンス同士でも互いを簡単に呼び出せるので、Singletonデザインパターンを頻繁に使います。

iOSのプログラミングでは、UIApplicationDelegate クラスは事実上シングルトンクラスです。シングルトンクラスであること、アプリ起動時最初に呼ばれるクラスであることなどからアプリ全体の動きに関わる管理の役割を果たすことが多いです。

FileQでも多くの箇所でこの特性を利用しています。

    FileQAppDelegate *appDelegate = (FileQAppDelegate*)[[UIApplication sharedApplication] delegate];
    appDelegate.assets = (NSMutableArray*)assets;
    [tableView_ reloadData];
    [[NSNotificationCenter defaultCenter]postNotificationName:NOTIFICATION_ASSETS_CHANGED object:assets];

上記の一行目 [[UIApplication sharedApplication] delegate]; は UIApplicationDelegate を取り出すメソッドです。
このメソッド１つで UIApplicationDelegate をどのクラスからでも呼び出せるので、UIApplicationDelegate に共有情報を
管理させて使うのに便利です。

2，複数のクラスから呼ばれる機能はシングルトンデザインパターンで専用のクラスを作る

事実上のシングルトンであるUIApplicationDelegateは、便利ですが何でもかんでも機能や情報を詰め込むのはメンテナンス性が下がり問題です。特定の機能については専用のクラスを作って共有するのが望ましいです。

Javaの場合、DIコンテナに頼ってしまえば、シングルトンにするためのメソッドを追加する作業は省けるのですが、Objective-CにはDIコンテナがないのでシングルトンにするメソッドを追加する必要があります。

以下はスマートフォン向け広告メディアであるAdMobの広告表示インスタンスを複数の画面で使いまわすためのシングルトン化するためのメソッドです。

+(GADMasterViewController *)singleton {
    static dispatch_once_t pred;
    static GADMasterViewController *shared;
    // Will only be run once, the first time this is called
    dispatch_once(&pred, ^{
        shared = [[GADMasterViewController alloc] init];
    });
    return shared;
}

クラス全体の説明はCreating A GADBannerView Singleton in AdMob Applicationsを参照してください。

+ で始まっているメソッドはObjective-Cでは staticメソッドです、インスタンス化しなくても使えるメソッドです。
シングルトン化のキモはこのインスタンスを取り出すメソッドを staticメソッドで定義します。

メソッドの中身も至ってシンプルです、iOS4以降で使えるようになったブロック処理(ここでは dispatch_once)をうまく使っています。

ブロック処理の中でインスタンス化( [[GADMasterViewController alloc] init]; )を行っています。
dispatch_once はその名の通り一度しか実行されないブロックなので、その中の処理も一度しか実行されません。
ですから GADMasterViewController のインスタンスは singleton メソッドから取り出す場合に限り常に１つ（同じインスタンス）です。

シングルトンクラスを呼び出す側も簡単です。

    GADMasterViewController *shared = [GADMasterViewController singleton];
    [shared resetAdView:self];

先に書いたように singleton メソッドはstaticメソッドなので、[クラス名メソッド名]で呼び出せます。
さらっと書いてしまいましたが実際使い始めてみるといちいちインスタンス化する手間なく使えるstaticメソッドって便利だな〜
と思うはずです。
シングルトンに限らずインスタンス化する必要があるかどうか吟味して必要がなければ積極的にstaticメソッドを使うことは
コードの安定化に役立つでしょう。

また、マルチスレッドで動作する複数のインスタンスからある処理が呼ばれる場合、排他処理が必要になることがあります。
この場合もシングルトンクラスを定義し、排他処理が必要な箇所(メソッド)で @synchronized（Objective-Cの場合）で括ることで割りと簡単且つ安全に排他処理が書けるようになります。