プログラミングのポリシーを色々追加していくエントリー
公開日:
:
最終更新日:2012/06/22
mycode
検索一発クンもおかげ様ですくすくと成長しておりまして、コーディングしていても、これまでのように勢いだけで書いていると行き詰まることが多くなってきました。
2010年12月にIS03を購入して以来、Android開発を始めたのですが、最近は当初のきたないコードをリファクタすることに工数をとられています。
そこで、機能追加や機能修正する際に影響範囲が瞬時に分かり、またその範囲が極力小さくするためにどうすべきかという、これまでのプログラマが至極普通に気をつけていることに、ようやく関心と実践が伴ってきたわけです。
このエントリでは、今後のブラッシュアップのため今気をつけていること、今後気をつけなければならないことを書いていきます。
設計の指針
- 影響範囲の把握が容易
- 影響範囲が小さい
- 設計書が必要ない
よくある話ですが、より保守性が高い設計を目指します。
保守性が高いとは前述のとおり、変更・追加による影響範囲の把握とその範囲を極力小さくできることです。
また、個人開発の場合、設計書はラフ画程度にしか作成せず、全くかかないこともよくあります。
しかし複数のアプリを並列で開発していると、久しぶりに手を付けるアプリのコードを見たときに、内容を思い出すまでにコードと追いかけっこして無駄に工数を費やして染まします。
そこでクラス名やメソッド名を見ただけて、その目的だけでなく全体の流れまで把握できるようになるので理想です。
もちろんこれはコーディングポリシーを統一すれば複数人での開発にも役立つと思います。
MVCを考える
PHPのフレームワークで初めて知った言葉ですが、Androidやiphoneでの開発に応用するようになり、少し開発が楽になりました。
Zend FrameworkのMVCしか実際に触ったことはないのですが、
処理の流れを切り盛りするController
ビジネスロジックを実装するModel
表示部分を担うView
とにクラスを分けて作るようにしています。
AndroidSDKもiPhoneSDKも画面設計をxmlやxibで行うのでViewの部分は独立し易くなっていますが、コードでUIを実装する必要があることもあるので注意が必要です。
・Controller
androidではActivity、iphoneではviewController。
基本的に、初期化とイベントの検知、ModelとViewの架け橋のみ行います。
具体的な処理は行いません。
イベントの発生を検知して、Modelクラスに処理を依頼、結果をViewに反映、という流れを意識しています。
・Model
実際のビジネスロジックを行うクラスをその目的毎に作成していきます。
また、DBやプリファレンス、ファイルI/Oはその取り扱いだけでコードが大きくなり易いのでUtilityクラスとして分けて作成します。
ModelからはViewやControllerにはアクセスしません。
・View
xmlやxibファイル以外にもViewをカスタムしたクラスなどを分けて作成します。
ListViewなどがこれにあたります。
Modelクラスが作成したデータを渡すだけで、よきに表示するようにクラスを設計します。
逆にView内でデータを処理するようなことはしないようにします。
メソッドの設計
Controllerクラス
1.全てイベント名をメソッド名にする
もちろん原則ですが、on○○のように定義します。
Controllerクラスの役割はイベントを検知してModelに処理を渡すことです。
イベントの発生とそれをハンドリングするModelクラスとを結びつけることを役割の念頭において定義します。
Modelクラス
1.publicメソッドを少なくなるように決める。
privateなメソッドは影響をそのクラス内のみに抑えることができます。
2.publicメソッドはなるべくイベント名をメソッド名にする
saveFile()ではなくonSaveFileSelected()などです。
処理が発生する起点は全てイベントです。
起点を押さえることでいつ呼ばれるメソッドなのかがすぐに分かりやすくなります。
saveFileとしてしまうと、ファイルを保存する複数のイベントから参照されている可能性があるため、影響範囲が特定できません。
イベントと1対1で対応することで影響範囲を特定することができます。
同じ処理をメソッドにまとめる場合はprivateメソッドで定義します。
例えば「ファイルに保存」をメニューから選択した場合とCtr+Sのショートカットから呼ばれた場合は
public void onSaveFileSelected(){ saveFile(); } public void onShortCutCtrS(){ saveFile(); } private void saveFile(){ }
のように書きます。
ソースの長さと深度
・長さ
恐怖の一本ソースが嫌われるように、クラスやメソッドの記述量も気にしたいものです。
場合によりけりで全く論理的な根拠はありませんが、クラスで1000行、メソッドで100行以内に収まればいいなあ、という気持ちで書いています。
・深度
ここではメソッドの中でまた別のメソッドを読んで・・・というメソッド呼び出しの多重度を深度と呼ぶことにします。
共通部分を切り出してメソッドにすることを続けていくと、自ずと深度が大きくなります。
二度同じコードを書くのは望まれませんが、深度をあげすぎるのはよくありません。
なぜなら、深度が深くなればなるほど可読性に欠けてきます。
あるメソッドがどこから呼ばれているか把握しきれなくなるので、影響範囲が分からず、逆に保守性が落ちてしまいます。
深度が大きくなりすぎるくらいなら、多少重複したコードを書いたとしても、メソッドを作り過ぎないようにします。
続く。。。
関連記事
-
投稿時のフォーマット
投稿時のフォーマットを策定 <p>サマリー</p> <a