無差別に技術をついばむ鳥

最近オブジェクト指向についての質問がよく来ますので、私が考えるオブジェクト指向の学習法などを囀ります。今まで私は何度かオブジェクト指向ネタを書いております。最初にそれを読んでください。
ネタつつき16−オブジェクト指向の難しさと、実装を知らない設計者が駄目な訳（その逆も真なり）。
ネタつつき30ーオブジェクト指向設計時に発生する問題
この二つを読めばオブジェクト指向の概要が分かって頂けると思います。これから先はこれを踏まえて書きます。

オブジェクト指向で一番最初に覚えるべき事は、オブジェクト指向が複数の概念を含んでいる事です。オブジェクト指向分析、オブジェクト指向設計、オブジェクト指向プログラミングの三つがあり、各概念も個人の実装形態がありますので複数存在します。その混沌とした現状を把握するとオブジェクト指向が理解しやすくなります。 つまり、オブジェクト指向とは、オブジェクトを中心に考えるという事であって、どのように中心に置くのかは提唱者によって異なるのです。
では、この混沌としたオブジェクト指向をどのようにして学べばいいのでしょうか？それは、分析・設計・実装を同時に学べばいいのです。ネタつつき16で書いているように、オブジェクト指向は三位一体なので、どれかを個別に学ぶと後の開発者人生に悪い影響を与えます。しかしだからと言って、この三つは同一概念でありません。何をオブジェクトとするのかなどの考え方は異なります。それは各段階の目的が違うからです。これを踏まえておかないと、三つ同時に学習しても分けがわからなくなります。では具体的にどう考えればいいのかという事をこれから書きます。


オブジェクト指向を学ぶ際には、一つのアプリケーションを作る事が基本です。そうしないと三位一体が体感出来ません。ですから最初にアプリケーションの仕様を決める所から始めます。このアプリケーションはなるべく簡単なもので、目的がはっきりしているものにして下さい。
仕様を決めたら、簡単な仕様書を書き、何をオブジェクトにするかを考える事から始めます。これがオブジェクト指向分析の練習となります。何をオブジェクトにするのかは厳密に定義されていませんが、名詞をオブジェクトの候補にするとよいでしょう。
オブジェクトを選んだら、UML図を書きましょう。そうする事により、最初に考えた仕様の足りない部分や、曖昧な部分について分かります。これがオブジェクト指向分析の目的です。
そして、不足している仕様要求や曖昧な部分を熟考してまた簡単な仕様書を作ります。次にUMLを書いて仕様を分析します。この作業を納得がいくまで繰り返します。 納得がいく形が出来たら次の段階に移ります。
此処で一つ注意して欲しい事があります。それは、オブジェクト指向分析はあくまでも現実をモデル化するものである事です。オブジェクトを実装する事を考えて書いてはなりません。コンピューターで現実のモデルをどのように表現するのかはこの段階で考えてはならないのです。

次はオブジェクト指向設計の学習です。オブジェクト指向設計では、オブジェクト指向分析で得た結果（現実をモデル化したUMLと適切な仕様書）を元にして、コンピューターでどに表現するのかを考えます。この段階でのポイントは、現実に存在しないものもオブジェクトにする点です。あまりやり過ぎるのは考え物ですが、コンピューターで適切に表現する際には、そういったヘルパーオブジェクトやコンピューター特有のオブジェクトなどが必要です。念のために言っておきますが、勿論この練習でもUML図を書いて下さい。
オブジェクト結合度が低い様にオブジェクトを考えましょう。オブジェクト結合度とは、簡潔に言うと各オブジェクトが他のオブジェクトに依存している度合いです。この度合いが高いと、再利用できない使いにくいオブジェクトになってしまいます。各オブジェクトは、役割を明確に決めてシンプルに定義して下さい。そうする事により、自ずと結合度が低いオブジェクト指向設計となります。
ここでも注意するべき点があります。それは、実装する言語を決めない事です。この段階では実装言語を特定してUMLを書かないで下さい。そうしないと、言語に依存した再利用しにくいオブジェクト設計になっていまいます。ただし、どのパラダイムの言語を使うかぐらいは決めておいた方がより実践的です。何故ならば、命令型言語と関数型言語のオブジェクトデザインはかなり違うからです。
※言語のパラダイムを考慮しないオブジェクト設計図を先に作る事も重要です。
この段階でも納得がいくまでUMLを書いて下さい。

漸く楽しいオブジェクト指向プログラミング段階です。オブジェクト指向設計で定めたUML図を元に、言語特性を考慮したオブジェクトを定義して下さい。ちょっと面倒かもしれませんが、いきなりプログラミングしてしまうと碌な結果になりません。実務を意識した練習ではUML図は必須のものだと考えて下さい。UML図を書き終わったら、テストを実装しましょう。テストファーストは現在の開発において常識と言っても過言ではありません。テストを考える事により、よりよい実装が行えますしより実践的な練習となりますので、面倒がらずに必ずテストを実装してください。
テストの実装が終わったら後はひたすらプログラミングするだけです。この時が一番楽しいと思う人は多いでしょう。思う存分オブジェクト指向プログラミングを満喫しましょう！


以上で私が考える学習法の説明は終わりです。これはあくまでも練習であり、よりオブジェクト指向に熟練するには実践が一番です。実務でどんどんオブジェクト指向をして行きましょう。もし貴方が一部のオブジェクト指向しか出来ない部署にいても、頭の中でオブジェクト指向分析・設計・プログラミングを行いましょう。そうする事によりオブジェクト指向能力が鍛えられます。
この記事はこれでおしまいです。この記事がオブジェクト指向を学習する人の参考になれば幸いです。では、よいオブジェクト指向を！

質問していた一人なので取り上げて頂いてうれしいです。

>それは、分析・設計・実装を同時に学べばいいのです。ネタつつき16で書いているように、オブジェクト指向は三位一体なので、どれかを個別に学ぶと後の開発者人生に悪い影響を与えます。しかしだからと言って、この三つは同一概念でありません。何をオブジェクトとするのかなどの考え方は異なります。それは各段階の目的が違うからです。


との事なのでオブジェクト指向"分析・設計・実装"とは段階と理解出来ました。


リンクされているエントリも読んだのですが、"オブジェクト"ってなんだ？？？になってしまいました…
自分の考えている"オブジェクト"とは、"もの"であって（動きと能力を纏めたもの）と考えているのですが、その考えがすでに間違っていますか？
根本的に間違ってたらごめんなさい。調べなおしてきます…

> リンクされているエントリも読んだのですが、"オブジェクト"ってなんだ？？？になってしまいました…
> 自分の考えている"オブジェクト"とは、"もの"であって（動きと能力を纏めたもの）と考えているのですが、その考えがすでに間違っていますか？
> 根本的に間違ってたらごめんなさい。調べなおしてきます…

間違っては居ないのですが、分析／設計／実装の各段階で出現するオブジェクトは少しずつ違います。
その辺に注意を払わないと混乱すると思います。
さらに、提唱者ごとに少しずつ違う凶悪な概念です。

分析・・・実際の問題領域における概念やもの。
設計・・・コンピューターシステムで設計する上で現れる概念やもの。
実装・・・データと振る舞いを一体化したもの。

つまり、段階により何をオブジェクトとして捉えるかが少しずつ違うのです。

トラックバックURL

FC2ブログユーザー専用トラックバックURLはこちら