クラスを作るタイミング
概要
プログラムを作成しているとき、何も考えなくても、初めの頃は簡単です。しかし、作成するにつれて処理内容が多くなり、複雑になってきます。このように、何か複雑になってきたと感じたときは、クラスや関数に分離するタイミングと考えるのが、ここでのアイディアです。
クラスへ分離するときには、人に仕事を頼む感覚で分離します。そのクラスにこんなことをやってもらおう、という意識で分離します。
背景
オープンソースのコードに習う
プログラムを作成しています。何も考えなくても、初めの頃は簡単です。しかし、作成するにつれて処理内容が多くなり、複雑になってきます。
一方、あるオープンソースのコードを見ていると、かなり細かく関数に分けられている印象があります。あまり細かく分けすぎると、コードがバラバラに分散しすぎたり、関数の名前が付けにくくなったりと、扱いにくい感じがします。
しかし、複雑になってきた自分のコードを解消するため、試しに、オープンソースのコードに習って、自分のコードをクラスや関数に分けてみました。複雑を解消する目的で、複雑になってきたと感じたときに、クラスや関数に分離しました。
すると、複雑だったものがスッキリとし、一度にいろいろ考えなくてはならなかったものが、小さな範囲を考えるだけでよくなりました。 このように分離することで複雑を解消できると分かり、他のときにでも使えるように考え方を汎化して、複雑と感じたときに分離する、といったアイディアに至りました。
何も考えずにPG→はじめの頃は簡単→何か複雑になってきたなあ→OpenSourceのコード(Blender...)を見ていると、結構関数に分けられている、関数多い→これもクラスに分けたら?→スッキリ、粒度が小さくなりすぎて扱いにくくなると思ってたけど。
どんなもの?
複雑と感じたときに分離する
プログラムを作成しています。初めの頃はコードも少なく処理内容も少ないので簡単です。しかし、作成するにつれて複雑になってきたと感じます。何か複雑になってきたと感じたときは、クラスや関数に分離するタイミングであると考えるのが、ここでのアイディアです。
人が仕事をするイメージで考えます。あるとき、仕事が増えてきて大変になりました。しかし、1人で全部の仕事をしようとすると大変です。誰か人を呼んでその人にやってもらいます。クラスへの分離も同じように、大変になってきたと感じたら、クラスを作ってそのクラスにやってもらうイメージです。
分離する方法
|
人に仕事を頼む感覚で分離 |
複雑と感じたときに、その都度、クラスへ分離します。はじめからクラス図などを使って、どうクラスを作るかを決めておく必要はありません。コードを書いていくうちに、自然にクラスが出来ていきます。
クラスへ分離するときは、人に仕事を頼む感覚で分離します。そのクラスにこんなことをやってもらおう、という意識で分離します。人に仕事を頼むときは、いろいろと細かくやってもらうことを指示しないと、その人を動かせません。クラスへ分離するときも、何をやってほしいかを指示します。
この指示は関数定義などの形で表して、インターフェースを定義するコードのように書きます。IDEのコード補間機能が動作する程度の定義のコードを書きます。指示の段階では、まだ定義を書くだけで、この部分の実装は後で行います。その代わり、これまで複雑と感じていた元コードの完成をいち早く目指します。クラスに分離して処理を減らしたので、元コードの部分は早く完成できるようになります。
public class {
public bool IsMeasured { get; }
public int WaitCount;
public CountMeasurement(IC ic) { }
public void Reset() { }
public void SetMyMeasuredCount(int c) { }
public void AddOtherMeasuredCount(int c) { }
public void Complete() { }
} |
何をやってほしいかをインターフェースのコードのように指示する例 |
はじめからどうクラスを作るかを決めておかなくてよい(クラス図などのように)⇔複雑と感じたときに、その都度クラスへ分離する | クラスを作るときは人に仕事を頼む感覚で。いろいろと指示しないとその人を動かせない→何を使って何をしてほしいかを指示=インターフェース→この指示が関数定義になる、このステップではまだ定義だけ、実装は後でその人に任せる感じ
分離してよくなる点
分離してよくなったと感じる点を挙げると、次の6つです。
1. |
小さな範囲だけ考えればよくなる |
考えないといけないものが少なくなります。 |
2. |
全部覚えていなくてよくなる |
沢山記憶していられなくなります。そんなときは、どんどん他人に任せてその部分は覚えなくてよいように出来ます。その代わりに、その人の使い方(どの順で、何を渡して、何を出すかなど)だけを覚えておきます。 |
3. |
対象が小さいとよくあるパターンに見えてくる |
クラスに分離すると、考えなくてはならない対象が小さくなります。すると、実装しようとしているコードが、実は、よくコードされるパターンであったことに気付くことがあります。対象が小さいと、見通しがよくなり、よくあるパターンに帰着することに気付きやすくなります。 |
4. |
折り重なっていた処理内容がそれぞれ外に出る |
折り重なっていた処理内容がそれぞれ外に出て、複雑さが減ります。そのコードの場所では、本当は何の処理をすべきかが分かりやすくなり、コードを書きやすくなります。 |
5. |
何のコードを書けばよいかが直ぐ分かる |
人に任せるときは、何をやってもらうかしっかり教えなければならないので、自然に、インターフェースとそこで何をするかが、しっかり決まります。すると、いざ実装するときになって、次にそこで何をすべきか、何のコードを書けばよいかが直ぐ分かるようになります。 |
6. |
元コードを早く完成できるようになる |
クラスに分離して処理を減らしたので、先まで複雑と感じていた元コードを早く完成できるようになります。 |
何も考えずにPG→はじめの頃は簡単→何か複雑になってきたなあ→1人で全部しようとするから大変... | 人を呼んでその人にやってもらうイメージ...
沢山記憶していられなくなる→どんどん他人に任せてその部分は覚えなくてよいようにする⇔その代わりその人の使い方を覚えておく必要がある(どの順で、何を渡して、何を出すか)=全部覚えていなくてよくなる、 考えないといけないものが少なくなる、小さな範囲だけ考えればよくなる、対象が小さいとよくあるパターンに戻るor見えてくる、折り重なっていたアスペクトがそれぞれ外に出る→複雑さが減る、人に任せるときは何をやってもらうかしっかり決める(教える)ので=インターフェースがしっかり決まる→何をすべきか=何のコードを書けばよいかが直ぐ分かる。
更新履歴 |
2008/10/27 v1 |
|
2009/09/25 v2 |
|
|
※ご意見、ご感想、改善点、その他の情報などがありましたら、メールにてお知らせ願います。
|