第4章　MyClip プロジェクト
ホーム		メール
目次		< 前ページ 次ページ >

MyClip プロジェクト

　この章からはMyClipという簡単なメモアプリケーションを作りながら学習を進めていきます。

MyClip プロジェクトの作成

　この項の説明は前章までの説明と重複する部分もありますが、このまま掲載することにいたします。

■ プロジェクトファイル

　Xcodeでは作成するプログラムをプロジェクトという単位にまとめて管理しながら作業を進めていきます。プロジェクト全体を管理するファイルは“プロジェクト名.xcodeproj”になります。このファイルをプロジェクトファイルと呼びます。そしてこのファイルをダブルクリックするとプロジェクトが起動しプロジェクトウィンドウが開きます。すべての作業はこのプロジェクトウィンドウから始めることになります。
　また、プロジェクトを作成するとプロジェクト名と同じ名前のフォルダが同時に作られます。必要なファイルなどはすべてこの中に格納されます。プロジェクトファイルもこの中に入っています。作業中はこのフォルダかプロジェクトファイルをDockに登録しておくと便利でしょう。

■ プロジェクトの作成

　ではプロジェクトを作成します。Xcodeの「ファイル」メニューから「新規プロジェクト…」を選びます。新規プロジェクトウィンドウで「Mac OS X」の「Application」から「Cocoa Application」を選びます。「オプション」のところには何もチェックをいれないように注意してください。「選択…」ボタンをクリックすると保存シートが降りてきます。名前を”MyClip”にして保存場所を決めて「保存」ボタンをクリックします。なお、これらの作業は第2章の「シングルトンアプリケーション」を参照すると分かりやすいでしょう。保存場所も2章で作成したデスクトップの”ObjC”フォルダか読者が選んだ場所に続けて保存すると分かり易くて良いでしょう。

■ Snow Leopardで登場した新しいクラス

　MyClipプロジェクトウィンドウが開きましたら左ペインの「グループとファイル」から”Classes“フォルダを選択します。

図 MyClipプロジェクトウィンドウ1

＜▽コメント＞
[このコメントを覚え書きのために残します。読者のかたは気にされずに読み飛ばしてください]
　このAppDelegateという新しいクラスの登場で、これ以降のすべてのサンプルが作り直しになります。しかも、このクラスはXcode 3.1 (Mac OS X 10.5) では動作しません。したがって「Xcode 3.1でもそのまま使っていただけます」という構想が水泡に帰します。なお、このXcode 3.2.1の登場は10/9（日本時間で10/10）です。
＜△コメント＞

モデルクラスの作成

　前章で作成したModelクラスと同じものをこの章でも作成します。ただし今回はObjective-Cのクラスファイルとしてはデフォルトの形であるヘッダファイルと実装ファイルが分かれるかたちになります。プロジェクトウィンドウのClassesフォルダが選択された状態で「ファイル」メニューから「新規ファイル...」を選んでください。

　なお、このようにあるフォルダを選択して新規ファイルをつくることによって選択されたフォルダに新しいファイルが作成されます。ただしこの左ペインのフォルダは実在しないスマートフォルダですので、実際にはプロジェクトフォルダの第1階層にファイルが作成されます。また、左ペインの違うフォルダや場所にファイルを作ってしまった場合でも後からドラッグして希望のフォルダに移動しても問題がでることはありません。左ペインの各フォルダについては後ほど説明いたします。

図 ファイル – 新規ファイル

　「新規ファイル」ウィンドウの左ペインでMac OS Xの“Cocoa　Class”を選び、右ペインで“Objective-C class”を選びます。“Subclass of”プルダウンメニューでは“NSObject”を選び「次へ」をクリックします。

図 新規ファイルウィンドウ

　「新規Objective-C class」ウィンドウでファイル名を“Model.m”にします。あとはデフォルトのままで結構ですが、一応次の点を確認しておきましょう。

• 「同時に“Model.h”も作成」にチェックが入っているか
• 保存場所が正しいか

問題がないようでしたら「完了」をクリックしてください。

図 新規Objective-C classウィンドウ

　MyClipプロジェクトウィンドウのClassesフォルダに“Model.h”と“Model.m”が追加されます。新規クラスを作成した場合は、通常このように“クラス.h”と“クラス.m”に分かれることになります。そして「クラス.h」には@interface部を、「クラス.m」には@implementation部を記述します。

図 MyClipプロジェクトウィンドウ2

■ プロジェクトウィンドウの「グループとファイル」左ペインについて

　このグループとファイルペインのことを知っておくことはプログラミングの効率を向上させるためにとても大事なことです。このペインの各フォルダはスマートフォルダと呼ばれるものになっています。スマートフォルダは実在しない見かけだけのフォルダで、目的のファイルやフォルダに素早くアクセスするために用意されています。実際にプロジェクトフォルダを開いても「グループとファイル」ペインのようなフォルダ（ディレクトリ構造）は存在していません。例えて言えばスマートフォルダには各ファイルのエイリアス（Windowsなどではショートカットと呼ばれるもの）が入っている感じになります。同じファイルを複数のスマートフォルダに入れておくこともできます。
＜▽コメント＞ [次の文章は後々のために残しておきます]
スマートフォルダに収納されているファイルやフォルダは絶対的な階層構造としてそのスマートフォルダに含まれているわけではありません。スマートフォルダは単なるみかけだけの実在しないフォルダです。それぞれの目的別のファイルやフォルダを素早く表示するために各目的別の架空のスマートフォルダに含まれているような見かけになっているだけです。実際にプロジェクトフォルダの中にもこの左ペインのようなファルダ（ディレクトリ構造）は存在していません。
＜△コメント＞

　このスマートフォルダの中でも最も良く使うことになるのが1番上のプロジェクト名のフォルダでしょう。このフォルダはアイコンのような見かけになっていますが実際にはフォルダになっています。このフォルダを選択すると「ファイル名」右ペインにこのプロジェクトに含まれているすべてファイルが表示されます。

図 グループとファイル – MyClip

　そして、あと2つ良く使うフォルダがあります。
「Classes」フォルダを選択すると、そのプロジェクトのために作成されたクラスファイルだけがファイル名ペインに表示されます。Xcodeでの作業の大半はこれらのクラスファイルへのコーディング作業が中心になります。

＜▽コメント＞
[次の文章をのちのちのために残しておきます]
　グループとファイルの中で次に良く使われるのは上から2番目のClassesスマートフォルダでしょう。このフォルダを選択するとプロジェクトの中で作成されたクラスファイルが右ペイン「ファイル名」に表示されて簡単にファイルを開けるようになります。

　なお次の図ではClassesスマートファルダはすでに閉じた状態になっています。
＜△コメント＞

図 グループとファイル - Classes

　もうひとつよく使うフォルダは、2章でも説明しましたが、グループとファイルペインの一番下にある“Interface Builder ファイル”フォルダです。このフォルダを選択するとファイル名ペインにはInterface BuilderというGUIを構築するツールのファイルだけが表示されます。

図 グループとファイル – Interface Builder ファイル

　最後に、良く使うわけではありませんが、アプリケーションの日本語化やその他の設定に必要なファイルだけが入っているのが“Resources”フォルダになります。

図 グループとファイル - Resources

　グループとファイルペインのそのほかのスマートフォルダなどについては追って説明いたします。

宣言ファイル（ヘッダファイル）

　では、さきほど作成した“Model”クラスのコーディングをはじめます。プロジェクトウィンドウのグループとファイルペインでClassesフォルダを選択し、ファイル名ペインでModel.hを選択してください。プロジェクトウィンドウの下部にコードが表示されます。なお、Model.hをダブルクリックした場合は独立したウィンドウでコードファイルが開きます。

図 MyClipプロジェクトウィンドウ3

　コード表示部の上端には「◀」、「▶」、プルダウンメニューなどのツールが並んでいます。それぞれの役割は次のとおりです。

　これらの機能はコードファイルを独立したウィンドウに表示させた場合も同じです。

図 左プルダウン

　コードの先頭にはコメントとして、ファイル名、アプリケーション名、作者名などがすでに書かれています。そしてそのあとからが実際のコード部分になりますが、すでにある程度のヒナ型が記述されています。「新規ファイル」ウィンドウのsubclass ofプルダウンメニューでNSObjectを選んでいたのでスーパークラスとしてNSObjectが記述されています。

■ Model.h

//
// Model.h
// MyClip
//
// Created by Fumihiro Tezuka on 09/10/10.
// Copyright 2009 viva Cocoa. All rights reserved.
//

#import <Cocoa/Cocoa.h>


@interface Model : NSObject {

}

@end

　このように@interfaceからひとつ目の@endまでがModel.hの内容となります。そしてこの“クラス名.h”ファイルのことを宣言ファイルもしくはヘッダファイルと呼びます。ではこのModel.hに前章で作成したModel.mのインタフェース部を書き加えます。太字で強調されている箇所がヒナ形に追加されるコードです。各コードの意味は第3章ですでに理解していただけていているものと思います。

＜▽コメント＞宣言ファイルやヘッダファイルと呼ぶことはすでに3章で説明済みですが、一旦このまま重複記述いたします。＜△コメント＞

#import <Cocoa/Cocoa.h>


@interface Model : NSObject {
   NSString *string;
}
- (void)setString:(NSString *)aString;
- (NSString *)string;
@end

定義ファイル（実装ファイル）

　プロジェクトウィンドウでModel.mを選択もしくはダブルクリックします。ヒナ型としてすでに記述されているコードは冒頭のコメントを省略すると次のとおりです。

#import "Model.h"


@implementation Model

@end

　この段階で最も大事なのは次のコードでしょう。

      #import "Model.h"

　このコードは前章のModel.mには出てきませんでした。このコードが行っていることは分割した宣言ファイルを読み込むことです。Modelクラスの仕様はすべて宣言ファイル（Model.h）に書かれています。そしてコンパイラはその情報（クラスの仕様）を必要とします。なぜならコンパイラはファイルごとに機械語に変換します。この変換される単位を翻訳単位とも呼びます。そしてこのModel.mを機械語に変換する時にはModel.hで宣言されているModelクラスの仕様がコンパイラにとっては必要な情報となります。

　前章のModelmの@implementationから2つ目の@endまでが、この章のModel.mの内容になります。そしてこの“クラス名.m”のことを定義ファイルもしくは実装ファイルと呼びます。ではこの章のModel.mに前章で作成したModel.mの実装部を書き加えます。太字で強調表示されている箇所がヒナ形に追加されるコードになります。各コードの意味は一部を除いて第3章ですでに理解していただいているものだと思います。

＜▽コメント＞ここでも定義ファイルや実装ファイルと呼ぶことは第3章で説明済みですが、一旦このまま重複説明いたします。＜△コメント＞

#import "Model.h"


@implementation Model

- (void)setString:(NSString *)aString
{
   [string release];
   string = aString;
}

- (NSString *)string
{
   return string;
}

@end

　今回もセッターメソッドの[string release];メッセージ式については第6章「メモリ管理」で説明することにさせてもらいます。

MVC

　今まで作成してきたクラスは“モデル”と呼ばれるクラスです。Objective-Cではモデルビューコントローラ（MVC）と呼ばれるデザインパターンに準拠するかたちでアプリケーションを構築していきます。

■ MVC

　初のオブジェクト指向プログラミング言語Smalltalkで提唱されたデザインパターンです。MVCはプログラムをモデルとビューとコントローラの3つの部分に分けて「プログラムの可読性」を向上させるものです。そしてこのデザインパターンはSmalltalkの直系子孫ともいえるObjective-Cにも引き継がれています。ただしSmalltalkで提唱されたときにはオブジェクト指向プログラミングじたいがまだ黎明期でした。そしてMVCも努力目標的な意味合いの多いデザインパターンでした。実際にMVCだけで解決できない場合も存在します。しかし多くの場合はかなり有効なデザインパターンだと言えます。Objective-Cプログラミングでは、このMVCに沿ってコーディングをしていきます。他のOOPでもMVCというデザインパターンは取り入れられていますがObjective-CほどMVCに準拠しようとする姿勢はないように見えます。しかしMVCに慣れるとプログラムの可読性が向上し、プログラムをどのような構造にするべきか、ということについて悩むことが減ることは確かです。

■ MVCの各役割

モデル

プログラムのなかでデータを担当する部分です。

ビュー

名前のとおりプログラムを使うユーザーの目に見えて、操作の対象となるボタン、アイコン、ウィンドウなどのことです。

コントローラ

3つの中で1番定義の難しい部分ですが、Appleのガイドブックによると「ビューとモデルの同期をとるもの」となっています。ビューに表示されているデータがユーザーによって変更されればすぐにモデルのデータも更新され（変更され）、モデルのデータが変更されればすぐにビューにもその変更が反映される（更新される）という役割です。一見シンプルで分かりやすい説明ですが、実際にコーディングしていくとこれだけでは説明が足りないことに気づきます。そこでアーロン・ヒレガス氏の「Mac OS X Cocoa プログラミング」を見ると、コントローラは次のことに責任を持つことになっていると書かれています。

＜▽コメント＞次のメモの中での「ユーザ」は引用文に付き「ユーザー」へ変更することは不可です＜△コメント＞

　このことをまとめるとコントローラの役割は次にようになります。

• 該当モデル・データのファイルへの保存（書き込み）
• ファイルやデータベースからのモデル・データのロード（読み込み、取得）
• ビューに対するモデル・データの表示
• ビューからのユーザ入力取得とモデル・データの更新

　Appleのガイドブックと比べるとファイルなどへの入出力という点が増えているだけですが実際にコーディングする場合に「これはモデルに含まれるのだろうか、それともコントローラに含まれるのだろうか」と結構悩むところです。これだけでも情報が増えるということは結構助かります。

　なおアーロン・ヒレガス氏はMac OS Xの前身となったNeXTSTEPを開発したNEXT社、およびApple社の両方で両社のプログラマにObjective-Cプログラミングを教えていたMacプログラミングの世界では有名な人物です。

Copyright 2006 - 2010 viva Cocoa. All Rights Reserved.