iOSアプリを作ってみる(2): Classの基本構成を考えてみた

今回、アプリを作るに当たっていくつかの本だったり、チュートリアル的なWebサイトの記事を読んでみました。その結果分かったのは、MVC (Model-View-Controlloer)というモデルに従いなさいという事。

MVCとは？

小難しい話は、これを読んでください >>> http://ja.wikipedia.org/wiki/Model_View_Controller 。

それだけだと切ないので、自分なりの理解を含めて少し書いておきましょう。オブジェクト指向言語なのでクラスを作りなさいという訳なんですが、そのときにModel, View, Controllerという3つのグループ分けをしなさいという事のようです。Modelってのはデータモデル、直感的に考えてデータベースからデータを拾ってきたモノを受ける場所と考えれば良さそうです。次のViewというのは、ユーザが見れる形に加工してやる階層、最後のControllerというのはUser Interfaceの部分なのかなと勝手に理解しました。

間違っていたら指摘してください。でも、もうこの理解で突き進んじゃいますけど。

なので、自分のイメージだとModelに該当する部分は本当にデータの構造だけを持たせてやる感じ。真ん中のViewのところでDBから拾ってきたデータを加工して表示させる。自分の例で行くと、正しい単語がDBに入っているので、それを拾ってきて紛らわしい選択肢を作ったりの準備をしてやる。最後のControllerの部分で準備したデータを表示させる、またユーザのリアクション(選んだ選択肢)を拾ってViewの階層に投げる。データを受け取ったViewの階層では、正解・不正解の判定をして統計情報の更新をして、それぞれの場合のリアクションを再びControllerの階層に戻してやるみたいな流れになるのかなと。

で、クラス構成を考えてみた

実際にクラスを定義しようという段になって、こんな感じで良いのかな？と考えてみたのが次の図です。ただ実際のクラス名ではありません。

左下のオレンジ色っぽいやつがSQLiteのファイル。これにアクセスするのがClass DBAccessなんだけれども、データを取り出したときのModelとして、Class Datastructureというのをデータの取り出し方に合わせて複数準備しておいて、DBから拾った内容をこれを経由して保存しておく。一方、拾ったデータを実際に加工するのは、Class GameManagementなんだけれども、そのときもClass Datastructureを使って取り出すようにしました。一見面倒くさいようなんだけれども、こうなっている理由はClass Datastructureで持っている属性はあくまでテーブルの項目なのに対して、実際に取得されるデータは複数エントリになる可能性も多い訳です。例えば、出題する単語の一覧となった場合に、数十個とか100個のデータを選択する訳で、そのためにわざわざArray(配列)をそれぞれのデータの取り出し型に合わせてClass Datastructure側に持たせるのはイマイチかなと。なので代わりに何でも入るNSArrayの箱を1つだけ用意しておいて、このArrayにDatastrucureをくぐらせたObjectを放り込んでおくと。

受け手となるClass Gamemanagementでは、何やらArrayが来たけどそのままでは読めない。なので、こちらからもClass Datastrucureをくぐらせてから1件1件のデータを読み込んで加工に移るという算段です。細かい加工を終えて出題の準備が出来たら、それをClass UIViewControllerを使って画面に表示させて、ユーザのリアクションを拾うという感じになります。とにもかくにも、こんな感じでClassの定義をあらかた決めてみました。あとで、色々面倒なことに直面するかも知れませんが、とりあえず今はこれで突き進みます。

てか、この説明読んで分かる人いるかな？(苦笑)

次ぐらいから、コーディングの話が出て来る予定です。ただ、少し時間が空くかも知れません。

（つづく）