*

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

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

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

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

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

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

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

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

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

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

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

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

JavaではDIコンテナ(SpringSeasar2)が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 を取り出すメソッドです。
このメソッド1つで 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 メソッドから取り出す場合に限り 常に1つ(同じインスタンス)です。

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

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

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

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

まとめ

例も含めると 結構長くなりそうなので このテーマは2回か3回に分けます。
次回書く予定の項目は以下のものです。

  1. Mediator デザインパターンを積極的に使う
  2. 出来るだけ早くエンティティクラスを定義して、クラス間の情報やりとりをシンプルにする
  3. エンティティクラスはO/Rマッパーと連動させると尚良し

デザインパターンは いろいろな種類があってパターンだけ説明されてもピンとこないことが多いのですが。全てのデザインパターンを覚えなくてはダメというものではないです。 使えそうなところから 少しづつ使ってみるだけでも十分です。

今回、説明したシングルトンは デザインパターンの中でも 意図を理解しやすく 有用性も高いのでぜひ活用して欲しいパターンです。

関連記事

iOSプログラミングのキモ(AppDelegate説明 デバッグをやりやすくするための工夫:NSSetUncaughtExceptionHandler )

デバッグはプログラミングを進めていく上で避ける事が出来ません。どうしてもバグは入ってきます。重要なの

記事を読む

iOSプログラミングのキモ(iOS7から使えるようになったマルチタスク機能、NSURLSessionUploadTask の困った現象)

このブログでも度々書いてきたFileQ iOS版ですが、今月末に Appleに申請できそうな

記事を読む

iOSプログラミングのキモ(デバッグをやりやすくするための工夫:コンソール・ログの出し方 )

iOS上でプログラミングをする時、ログ出力用の関数としてNSLogという関数をよく使います。NSLo

記事を読む

iOSプログラミングのキモ(拡張子がpchというファイルの役目)

XCodeで プロジェクトを作成すると、-prefix.pch というファイルができています。このフ

記事を読む

iOSプログラミングのキモ(2:ソースコード概説 )XCode

iOSプログラミングでは Appleが提供している XCodeという開発ツールを使います。

記事を読む

iOSプログラミングのキモ(2:ソースコード概説 )主要なObjective-Cソース・ファイル一覧

QTubeの主要Objective-Cのソース一覧です。 iOSでは アプリを作る場合 Objec

記事を読む

iOSプログラミングのキモ(2:AppDelegate説明 )

実際の AppDelegate.h、AppDelegate.m のソースコードです AppDe

記事を読む

iOSプログラミングのキモ(MainViewController説明)

個別の画面のコードについて解説を進めていきます。最初は起動直後の画面であるMainViewContr

記事を読む

iOSプログラミングのキモ(複雑な画面を複数のViewControllerで制御する その2)

先週は、複数のViewControllerで1つの画面を構成する話のうち、親ViewControll

記事を読む

サイト管理 Mezzanine

Django上で動くCMS Mezzanine 用のモジュールを作ってみる その1

Django上で動くCMS Mezzanine上で動く、モジュールを作っていきます。 Mezzan

記事を読む

Message

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

日本語が含まれない投稿は無視されますのでご注意ください。(スパム対策)

FileQ Hosting 月額99円 容量1GB


サイト管理 Mezzanine
Django上で動くCMS Mezzanine 用のモジュールを作ってみる その1

Django上で動くCMS Mezzanine上で動く、モジュールを作

ホーム Mezzanine
Django上で動くCMS Mezzanine を インストールする MacOSX Yesemite 編

Mezzanineは Django WEBフレームワーク上で動くCMS

EclipseにGWT(Google Web Toolkit) Plugin for Eclipseを入れようとしてハマった

最近PHPでちょっとした業務システムを作りました。業務システムの特徴と

ブログを半年やった成果を Google Analytics から眺める

今年の1月からブログを書き始め、そろそろ半年が経とうとしています。

母校で特別 講義をやってきました。

少し 間が空いてしまいました(^_^;) ちょっと前になりますが

→もっと見る

mautic is open source marketing automation
PAGE TOP ↑