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

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

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


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

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

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


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

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

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


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


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

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

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

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

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

インドリさんのオブジェクト指向記事、待ってました！

いままでいくつかのオブジェクト指向関連の書籍を
呼んだことがありますが、
概念はなんとなく理解できても、実際のコーディングでは
どう書くのか？というところが中々理解しづらく、身につきません。

なので、インドリさんがオブジェクト指向を取り入れたコードを是非見てみたいです！

> なので、インドリさんがオブジェクト指向を取り入れたコードを是非見てみたいです！

今忙しいので少し待ってね。

> 概念はなんとなく理解できても、実際のコーディングでは
> どう書くのか？というところが中々理解しづらく、身につきません。

オブジェクト指向プログラミングの話しですよね。
という事は、どう書くかというのは文法の話しでしょうか？
それとも、よい実装方法の話しでしょうか？
よい実装法ならば、三位一体であるという事を把握する事と、練習する事が肝心です。
三位一体で実践しないと、使い辛いへんなオブジェクトを量産する事になってしまいます。
つまり、自分で考えて実践が大事なのです。
記事を参考にして一度自分で実践してみてください。

インドリさんこんにちは
なかなか、まとまった記事でうなずきながら読ませていただきました。
１点だけ、書かれていないことで、重要なことがあると思ったので質問です。

>よい実装法ならば、三位一体であるという
これは、おそらく、、分析・設計・実装それぞれのフェーズでＵＭＬを書くということ。
ならびに、それぞれのＵＭＬの結果は違うものになるということ。
を言っているのだと思います。
なので、それぞれを学ぶべきであるということだと思います。
だとすると、すごく当然で、その通りと言えますね。


しかし、ここで問題が発生します。勉強のためにそれぞれのＵＭＬ作成を実践したとして、それぞれの結果が、正しい、もしくは、ほぼ正しい、ということを判定する必要があると思いますが、学んでいる人たちはどのようにして判定するのでしょうか？

私はこの「正しさのジャッジ」が、独学では不可能でネックになると思うのですが、何か良い方法はあるのでしょうか？
回数をこなすといつか判るというときが来るとは思いますが、それでは、学び方として魅力のある方法とは思えませんし。

どうもoumiさん。
> インドリさんこんにちは
> なかなか、まとまった記事でうなずきながら読ませていただきました。
> １点だけ、書かれていないことで、重要なことがあると思ったので質問です。
>
> >よい実装法ならば、三位一体であるという
> これは、おそらく、、分析・設計・実装それぞれのフェーズでＵＭＬを書くということ。
> ならびに、それぞれのＵＭＬの結果は違うものになるということ。
> を言っているのだと思います。

いいえそれだけではありません。
よいオブジェクトは、分析／設計／実装の三段階を経ないと生まれない事を指しています。

> 私はこの「正しさのジャッジ」が、独学では不可能でネックになると思うのですが、何か良い方法はあるのでしょうか？
> 回数をこなすといつか判るというときが来るとは思いますが、それでは、学び方として魅力のある方法とは思えませんし。

実際にオブジェクトを再利用すればわかります。
よいオブジェクトならば再利用しやすく、悪いオブジェクトの場合は再利用しにくいのです。
やはり実体験を伴わないとオブジェクトに関する思考能力はUPしません。

> よいオブジェクトならば再利用しやすく、悪いオブジェクトの場合は再利用しにくいのです。

それは分析・設計段階で出てきたオブジェクトが正しいかの判断にも使えますか？

> > よいオブジェクトならば再利用しやすく、悪いオブジェクトの場合は再利用しにくいのです。
>
> それは分析・設計段階で出てきたオブジェクトが正しいかの判断にも使えますか？

もちろんです。
そうでなければ、その様な開発プロセスの存在意義がありません。
前段階の成果が正しいのか、それとも後の段階が正しいのかを見抜けないようでは、オブジェクト指向に熟練しているとはいえません。
その目を養う訓練でもあるのです。

> 前段階の成果が正しいのか、それとも後の段階が正しいのかを見抜けないようでは、オブジェクト指向に熟練しているとはいえません。

「それとも」という接続詞を使うということは、正しいのは前段階か後段階のどちらか一方である、ということですかね？
ちなみに、「前段階」「後段階」というのは、設計段階から見て分析段階が前段階、実装段階が後段階ということでよいですか？

さて、「再利用」がひとつのキーワードですが、この言葉にはいくつかの異なる意味がありますね。
あるプロジェクトで書いたソースコードを別のプロジェクトでも使うこと、という意味が一般に多いと思います。
他には、インドリさんの↑のレスでは、前段階でできたものを後段階で「再利用」することも意図していると思われますが、こういうのも「再利用」と言うのでしょうか。

> 他には、インドリさんの↑のレスでは、前段階でできたものを後段階で「再利用」することも意図していると思われますが、こういうのも「再利用」と言うのでしょうか。

デザインパターンの様に、使いまわし出来るオブジェクト指向設計がよいでしょうか？
それとも、プロジェクト固有の設計結果だけに止めておきますか？
それを考えると良いと思います。

色々な人がこの記事を読むと思いますので、念のために書いておきます。
オブジェクト指向の結果生まれる資産はコードだけではありません。
ちゃんとしたドキュメント、UML図、社員の経験などもオブジェクト指向の結果生まれる資産です。
これらの資産を大事にしないのであれば、オブジェクト指向を有効利用できているとはいえません。

流れを切ってしまいそうで怖いんですが、強行で質問させて下さい！

>分析／設計／実装の各段階で出現するオブジェクトは少しずつ違います。

とのことなのですが、"分析、設計、実装"で扱うオブジェクトの細かさが違うと認識でよろしいでしょうか？
うーん、細かいと言う表現もおかしいですかね？

すでに間違っていたら意味のない質問なんですけど

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

"分析"はリアルをコンピューターシステム化するにあたっての調整なのかなと思っています。
勘違いしているようでしたら、ご指摘お願いします。

認識が合っている前提なのですが、"設計"と"実装"は同一に出来ないものなのでしょうか？

"設計"と"実装"の差が見えて来ないです・・・
言語の差を吸収するのが"設計"になるのでしょうか？

> とのことなのですが、"分析、設計、実装"で扱うオブジェクトの細かさが違うと認識でよろしいでしょうか？

抽象度ですね。

> "分析"はリアルをコンピューターシステム化するにあたっての調整なのかなと思っています。
> 勘違いしているようでしたら、ご指摘お願いします。
>

一言で言うのならば現実の抽象化です。
現実は複雑なので、人間が扱いやすいように「情報システム化する範囲」でモデル化する思考法なのです。
分析が見当はずれですと後の段階（正確に言うとプロセス）で非常に困ることになります。

>実際にオブジェクトを再利用すればわかります。
>よいオブジェクトならば再利用しやすく、悪い>オブジェクトの場合は再利用しにくいのです。
>やはり実体験を伴わないとオブジェクトに関する思考能力はUPしません。

>実際にオブジェクトを再利用すればわかります。


やはり、実体験を何度も経験する必要があって、しかも良いオブジェクト・あまり良くないオブジェクトを判断できるようになるためには、相当数の経験をこなさないと駄目なようですね。
現実問題、プロジェクトの外へコードを持ち出すということは、まずできない昨今の時勢から考えて、数年では習熟するのが無理な言語と聞こえなくもないですね。
別のプロジェクトへ移動すると、またまったく違う観点や要点を突きつけられますし。


私は、新入社員〜５年生くらいまでの人材（数千人いるのですが）が、素早くOOA〜OOPまでをカバーできる人材に育てる方法が無いかと模索しています。
思ったいたとおり、何も知らない人に、素早くというのはちょっと難しいようですね。となると、今までとおり、10年越しで経験を積んでということになりますか・・


インドリさんは30前後だそうで、何か良い方法を知っているかと思ったんですけど。
何か早く習得させるためのコツみたいなものはないでしょうか？ただで聞こうってのもむしがよすぎるしますが・・

私は、オブジェクト指向に光が当たった頃は、歳もだいぶいってましたので私の体験では、いまどきの若い人には、参考にならないと思うのですね。思考のベクトルも違うでしょうし。かといってMSCとかはお金高いし・・(^^;

何か良い考えはないですか？

> インドリさんは30前後だそうで、何か良い方法を知っているかと思ったんですけど。
> 何か早く習得させるためのコツみたいなものはないでしょうか？ただで聞こうってのもむしがよすぎるしますが・・
>
> 私は、オブジェクト指向に光が当たった頃は、歳もだいぶいってましたので私の体験では、いまどきの若い人には、参考にならないと思うのですね。思考のベクトルも違うでしょうし。かといってMSCとかはお金高いし・・(^^;
>
> 何か良い考えはないですか？

およそ10年この業界に居ますが、オブジェクト指向だけで10年かかったのではありません。
私の場合、情報処理技術のほぼ全てを学んでいるので余分にかかっています。
※未だに学習中。
ですから希望はあると思います。
オブジェクト指向を極めるというレベルならば、一生かかるでしょうが、小さなプロジェクトがこなせる程度ならば2・3年でも可能だと思います。
一番最短なのは命を賭けさせる事なのですが（私の場合は正しくこれ）、しかしそれは常識的に言っても到底無理なので、ある程度の切迫感を出すのが一番の薬になると思います。
その第一段階として、給与を完全能力制するのが良いでしょう。
プロジェクトで成果を上げれば、その月の給与を上げ、逆の場合は容赦なく下げる。
こういった切迫感は人間を鍛えます。
ですが、注意しなければならないのは、「能力を公平に評価する」という点です。
これは管理職に任せていれば良いというものではなく、ご自身の目で確認する必要があります。
何故ならば、管理職自身に能力がなければ正等に評価できませんし、優秀な人を潰すために嘘の報告をするケースが多いからです（日本は足を引っ張る文化がある）
また、冒険させる事も重要です。
余りにもミスを過大に評価すると人間は冒険しなくなり、ついには自分の身の保身のため「オブジェクト指向なんてしない」（駄目上流技術者の量産）という事になります。
随分荒い説明ですが、こういった組織論は多分oumi さんの方が詳しいと思いますので省略します。
※oumi さんの立場が分かればもっとアドバイス出来るかもしれません。

なんだか、ＯＯを理解するためには、給与制度次第だ、組織の形の問題だと読めるのですが。そういうことですか？

そうだとするならば、組合のある企業ではＯＯを理解できる人材は育たないと言う事に等しくなってしまいます。
なぜなら、給与というのは、企業と組合の交渉の上になりたっているからで、昨今は組合のほうが圧倒的に力が強いのです。組合というのは社会主義というか共産というか、とかく出る杭をきらう傾向にあります。よく言えば、「公平感」を大事にするということです。企業はどんどん杭に出てほしいのですが、組合がこれに歯止めをかけてしまいます。組合の問題は、企業から直接手を入れるということはできません。

ですので、純粋に、ＯＯの理解を深めていく方法は無いものでしょうか？
なぜ、オブジェクト指向の理解を深めるために、給与制度を変更しなければならないのか、理解に苦しみます。


また、「能力を公平に評価する」事は、そのような努力は必要ですが、不可能です。なぜなら、日本人は評価される事になれていないため、他人の評価やアドバイス、特にネガティブな評価内容は受け入れないようなベクトルを持っている人が多いのです。これに対し米国などでは、昔から民族性として、他の評価を受け入れることは当たり前となっています。ですので、インドリさんがやっているような自己研鑽は自分の評価を上げるために当然の事として行われます。残念ながら日本はそうではない・・・
ですので、評価し、給与に直接反映させるという「成果主義」を寝ず貸せるには時間がかかります。おそらく何世代も。日本は「能力主義」ですから。
※見てて、知らない人のために言っておくと「能力主義」というのは、能力がある人が給与が高いということではありません。この場合はどちらかというと「成果主義」といいます。能力主義とは、たとえば、
・C++を２年やっていた人
・C++を４年やっていた人
では「おそらく」４年やっていた人のほうが能力が「あるはずだ」という客観的想定に基づく評価をしていく方法です。ですので、年齢によって給与が高くなるのです。


組織を欧米並みにしてくというのは、ちょっとスケール感が大きすぎる話ですので、もうすこし「言語そのものの理解を深める方法」という観点で何かないでしょうか？

> 組織を欧米並みにしてくというのは、ちょっとスケール感が大きすぎる話ですので、もうすこし「言語そのものの理解を深める方法」という観点で何かないでしょうか？

ごめん。立場が分からないものだから一番効果が高いものを書きました。
oumi さんの立場を教えていただけると、その視点からのなんらかのアドバイスが出来ると思います。

先に書いたように、現在は、

私は、新入社員〜５年生くらいまでの人材（数千人いるのですが）が、素早くOOA〜OOPまでをカバーできる人材に育てる方法が無いかと模索しています。

といったことを考える部署です。
もうひとつ大きなミッションとしては、Java、UNIX、Oracle といった系統の仕事が多いので、今後MS系案件が激増する予定ですので、社員を以下にしてすばやく、.Netの知識水準を、ある一定レベルまで引き上げるか、について検討する。といったような仕事をしています。

立場って、こういうことじゃだめですか？
企業名と役職の提示が必要ですか？
既に、某コミュニティで結構漏らしているので判っているかと思ったんですけど・・
はっきりと言うと、何かと問題あるかもなので、この程度で簡便してほしぃのですけどねー。

私はこの「正しさのジャッジ」が、独学では不可能でネックになると思うのですが、何か良い方法はあるのでしょうか？
回数をこなすといつか判るというときが来るとは思いますが、それでは、学び方として魅力のある方法とは思えませんし。

という質問を投げかけましたが、これについては、何かありますでしょうか？
「肝心な話題」がどっかいっちゃってるのですが・・・

> 私はこの「正しさのジャッジ」が、独学では不可能でネックになると思うのですが、何か良い方法はあるのでしょうか？
> 回数をこなすといつか判るというときが来るとは思いますが、それでは、学び方として魅力のある方法とは思えませんし。
>
> という質問を投げかけましたが、これについては、何かありますでしょうか？
> 「肝心な話題」がどっかいっちゃってるのですが・・・

最初に自分で使わないと分からないと答えました。
オブジェクトに絶対的な正しさなんてありません。

> 先に書いたように、現在は、
>
> 私は、新入社員〜５年生くらいまでの人材（数千人いるのですが）が、素早くOOA〜OOPまでをカバーできる人材に育てる方法が無いかと模索しています。
>
> といったことを考える部署です。
> もうひとつ大きなミッションとしては、Java、UNIX、Oracle といった系統の仕事が多いので、今後MS系案件が激増する予定ですので、社員を以下にしてすばやく、.Netの知識水準を、ある一定レベルまで引き上げるか、について検討する。といったような仕事をしています。
>

先ず第一に明確な目標を立てて下さい。
オブジェクト指向が出来る人材と言われても、どの程度の期待をしているのか分からないと答えようがありません。
それから、プロジェクトの詳細なログをとっていますか？
ログをとっていれば、諸先輩方の思考を学ばせる事より上達させる事が出来ます。
最後に、社員にとってのメリットは何ですか？
人間はメリットがないとやりません。
学習はモチベーションが命です。
本人にやる気がなければどのような手段でも上達しません。
※貴方が権限がわからないので答えにくいですね。

揚げ足をとるわけではないのですが、

>最初に自分で使わないと分からないと答えました。
>オブジェクトに絶対的な正しさなんてありません。

これは、私の質問に対する答えではないと思いました。


>しかし、ここで問題が発生します。勉強のためにそれぞれのＵＭＬ作成を実践したと
>して、それぞれの結果が、正しい、もしくは、ほぼ正しい、ということを判定する必
>要があると思いますが、学んでいる人たちはどのようにして判定するのでしょうか？
> 私はこの「正しさのジャッジ」が、独学では不可能でネックになると思うのですが、何か良い方法はあるのでしょうか？
> 回数をこなすといつか判るというときが来るとは思いますが、それでは、学び方として魅力のある方法とは思えませんし。

といいました。
質問の時点で既に「最初に自分で使わないと分からないと答えました。」の最初に使うということについては、クリアされています。
そしてもとより、絶対的な正しさを望んではいません。そんな事も示唆していません。
正しさのジャッジが、独学では難しいのではないか？と言っているだけです。

なので、何か良い方法があるのかな？という質問です。



途中で、なんだか勘違いさせてしまったかもしれませんが、（誘導したわけじゃないですよ）社員とかプロジェクトとかについては、社内事情なのでどうでも良いのです。
（そんなことを聞くつもりは毛頭ありませんし、まともに聞くならお金払いますし、ネットでだらだら聞ける話のわけもありません。）


気になっているのは、１点だけ！
作成した、UMLやコードの「正しさのジャッジ」が、独学では不可能でネックになると思うのですが、何か良い方法はあるのでしょうか？

これだけなのです。



私の肩書き関係ないですよねたぶん。

> 途中で、なんだか勘違いさせてしまったかもしれませんが、（誘導したわけじゃないですよ）社員とかプロジェクトとかについては、社内事情なのでどうでも良いのです。
> （そんなことを聞くつもりは毛頭ありませんし、まともに聞くならお金払いますし、ネットでだらだら聞ける話のわけもありません。）
>
>
> 気になっているのは、１点だけ！
> 作成した、UMLやコードの「正しさのジャッジ」が、独学では不可能でネックになると思うのですが、何か良い方法はあるのでしょうか？
>
> これだけなのです。

じゃあ、

>私は、新入社員〜５年生くらいまでの人材（数千人いるのですが）が、素早くOOA〜OOPまでをカバーできる人材に育てる方法が無いかと模索しています。 」

これは一体なんだったのでしょうか？
それはさておき、初めから何度も言っていますが、自分で考えないとオブジェクト指向は身につきません。
絶対的に正しいオブジェクトというものが存在しないのですから、独学ならば実体験に基づいて自分で判断するしかありません。
それが出来ない人には学習なんて出来ません。

あと、これは情報処理技術全般についても同じです。
自分で正しさを判断できず、何かに頼る事しか出来ない人には独学は出来ません。
自分で判断する事が出来ない人は指導してもらうしかありません。
また、目標が曖昧であると学習出来るはずがありません。
曖昧な質問を繰り返さずに、目標を明確に設定してください。

また曖昧な質問が来そうなので追記します。
手始めに結局貴方が学習するのか、他人に学習させたいのかをはっきりさせてください。

やっと、言っていることが判ってきました。
（元記事の抽象度にあわせて質問したつもりなんですけど、なぜお怒りなのかわかりませんが。）


>それはさておき、初めから何度も言っていますが、自分で考えないとオブジェクト指向は身につきません。

これを踏まえたうえで、それでも早く覚えさせる方法、コツは無いか？って聞いたら、死ぬ目に合わせろとか、組織の形に話がずれていったわけですが・・まぁそれはおいといて、呼び水がなんだっかも目をつぶるとして・・・ｴﾍｴﾍ



私は「考えた結果が正しいかをジャッジする方法」と聞いてるのに対し「自分で実践し、判断するしか無い」的な回答ですので、ここで、何か、インドリ流の「コツ」があるかとおもったんですけど、無いのかなぁ、残念。

私は１０年越しになると思っているので、何か別のコツみたいなものを持っているのじゃないかと思ったのですね。
結局、「やはり実体験を伴わないとオブジェクトに関する思考能力はUPしません。」
に尽きるのでしょう・・・コツも良い方法もそうそう無いってことですね。
特に、独学ですと、間違った方向へいっちゃうかも知れないわけですから、独学ってのは運・不運やその人のセンスに左右されることが多くなっちゃいそうですね。
独学でやる人には、教えてもらう場や人を準備したほうが良いですよって事になりますかね。
（当然、自社内でも紙ベースだけで何か効果の高い方法があるかというと、無いということですね。）


１０年はなげぇ〜のかもしれませんが、結局実践するにしても、業種やシステムの特性によって、オブジェクト（という物）自体の定義も必要な抽象度も変わっちゃいますからね。そういったことを踏まえて、なんだかんだ言って、自分で満足できるレベルには１０年ちかくかかっているんじゃないかなぁと思っているのです。まぁ馬鹿だからかもしれませんが。C/C++が登場したときって、良い本も何もなかったですからね、かなり苦労したのでした。今の時代は違うかもしれませんが。

ＯＯができるというのは、業種やシステムの特性を如何にして、必要なオブジェクトに纏め上げるかって事になっちゃいますよね。やっぱり経験が物を言うので、なが〜い時間がかかっちゃうのでしょうね。まぉあ人によってバラツキがあるでしょうけど。


ちなみに、私はＯＯについて勉強する予定はありませんよ。終わってますから。私のＯＯレベルはどう言えば伝わるかは判りませんが、今は.NET Framework自体のソースコードを読みながら、MSの人ってすごいねぇやっぱとか言っている感じです。
業務レベルでは、ＯＯを業務そのものに持ち込む必要があまりないので、大々的に取り扱った経験はないですね。大々的にというのは、組織もデータも伝票もありとあらゆるリソースも、すべてをオブジェクトにして云々なんていう、夢のようなシステムはやったことが無いという意味です。
もっともNameSpaceの設計や、様々なインタフェースの設計や、データアクセス層の設計だけだとしても、ＯＯでしょといわれると、まぁそりゃそうだけどってなりますが・・・

> やっと、言っていることが判ってきました。
> （元記事の抽象度にあわせて質問したつもりなんですけど、なぜお怒りなのかわかりませんが。）
>
怒っていません。貴方の質問が曖昧なので聞いているだけです。
自分がやるのか他者へ学習させるのかは手法が大分違います。

>
> >それはさておき、初めから何度も言っていますが、自分で考えないとオブジェクト指向は身につきません。
>
> これを踏まえたうえで、それでも早く覚えさせる方法、コツは無いか？って聞いたら、死ぬ目に合わせろとか、組織の形に話がずれていったわけですが・・まぁそれはおいといて、呼び水がなんだっかも目をつぶるとして・・・ｴﾍｴﾍ
>
という事は、他者に修得してもらう方法ですか？
その人にやる気になってもらう方法を考えるのが第一だと思います。
貴方が立場も関係なしに、オブジェクト指向を修得してもらいたいと願っているだけでは、多分他者はいう事を聞いてくれないでしょう。
その人はその人の意思で動くはずです。

>
>
> 私は「考えた結果が正しいかをジャッジする方法」と聞いてるのに対し「自分で実践し、判断するしか無い」的な回答ですので、ここで、何か、インドリ流の「コツ」があるかとおもったんですけど、無いのかなぁ、残念。
>
独習するという事は自分で判断する事を意味しています。
自分でその物事を正しいのか判断する目を鍛えない事には意味がありません。
それに、そもそも正しいとは何を持って正しいのですか？
オブジェクト指向で何を実現したいのか曖昧すぎて分かりません。
正しさは時と場合によります。


> 私は１０年越しになると思っているので、何か別のコツみたいなものを持っているのじゃないかと思ったのですね。
> 結局、「やはり実体験を伴わないとオブジェクトに関する思考能力はUPしません。」
> に尽きるのでしょう・・・コツも良い方法もそうそう無いってことですね。
自分で体験するのが一番の最良の方法です。
条件が「独習」なのですからね。
それに、オブジェクト指向の学習法は個人差があります。
目標となる人が曖昧なまま、なおかつ想定レベルも曖昧なまま言われても答えようがありません。


> 特に、独学ですと、間違った方向へいっちゃうかも知れないわけですから、独学ってのは運・不運やその人のセンスに左右されることが多くなっちゃいそうですね。
> 独学でやる人には、教えてもらう場や人を準備したほうが良いですよって事になりますかね。
> （当然、自社内でも紙ベースだけで何か効果の高い方法があるかというと、無いということですね。）
>
ですから最初に組織的にやるのがいいといったのですが・・・
貴方が独習だと返事をしてきたので困っているわけです。


>
> １０年はなげぇ〜のかもしれませんが、結局実践するにしても、業種やシステムの特性によって、オブジェクト（という物）自体の定義も必要な抽象度も変わっちゃいますからね。そういったことを踏まえて、なんだかんだ言って、自分で満足できるレベルには１０年ちかくかかっているんじゃないかなぁと思っているのです。まぁ馬鹿だからかもしれませんが。C/C++が登場したときって、良い本も何もなかったですからね、かなり苦労したのでした。今の時代は違うかもしれませんが。
>
> ＯＯができるというのは、業種やシステムの特性を如何にして、必要なオブジェクトに纏め上げるかって事になっちゃいますよね。やっぱり経験が物を言うので、なが〜い時間がかかっちゃうのでしょうね。まぉあ人によってバラツキがあるでしょうけど。
>
想定レベルにもよります。
前にも言いましたが、小規模システムに対処するぐらいのレベルならば2・3年でもOKです。

>
> ちなみに、私はＯＯについて勉強する予定はありませんよ。終わってますから。私のＯＯレベルはどう言えば伝わるかは判りませんが、今は.NET Framework自体のソースコードを読みながら、MSの人ってすごいねぇやっぱとか言っている感じです。
> 業務レベルでは、ＯＯを業務そのものに持ち込む必要があまりないので、大々的に取り扱った経験はないですね。大々的にというのは、組織もデータも伝票もありとあらゆるリソースも、すべてをオブジェクトにして云々なんていう、夢のようなシステムはやったことが無いという意味です。
> もっともNameSpaceの設計や、様々なインタフェースの設計や、データアクセス層の設計だけだとしても、ＯＯでしょといわれると、まぁそりゃそうだけどってなりますが・・・

自身が勉強しない事を他者へ強要するつもりですか？
貴方が立場も関係なく、他者へオブジェクト指向の学習を押し付けるというのは理不尽だと思います。
それに、自身が分からない事を他者へ教える事は出来ません。


今までのやり取りからいいますと、貴方様は余りにも質問に一貫性がなさ過ぎます。
オブジェクト指向を他者へ教えたいが自分は学習しないなどの矛盾した言動をとる限り、それは無理だとしか答えることが出来ません。

分かりやすいようにはっきりするべき事を書きます。

・自分で学習したいのか、他者に学習させたいのかをはっきりさせて下さい。
・それは組織的にやるのか、個人レベルでやるのかはっきりさせて下さい。
・想定レベルをはっきりさせて下さい。

先ずはこの三点をはっきりと書いて下さい。

うーん、どうも全然本筋と違う部分に反応されまくっちゃうので、困りました・・


.NET Frameworkのソースを読んで、関心するレベルって、インドリさんの中では、ＯＯ知らない人って位置づけなのでしょうか。そういわれるとMS本社の連中も泣くでしょうね。（.NET で作成されたソースと勘違いしたのかな？）まぁ、コードが読めるだけでしょっていっちゃうと、そうかもしれませんけどね。

勉強する予定が無い＝勉強するつもりがない、っとこれも勘違いしたのかな？
既に（それこそ実践込みで）勉強しまくって終わってるつもりなんですけど・・・C++が登場したときの話もしたし・・・伝わらなかったか・・・（一生勉強だとか禅問答的なことはおいてね）

>自身が分からない事を他者へ教える事は出来ません
どこをどう読むと、ＯＯ知らないことになっちゃうのかな？そりゃＯＯに関する全てを網羅しているかといわれれば違うと自信もっていえますが。

>オブジェクト指向を他者へ教えたいが自分は学習しないなどの矛盾した言動をとる限り
どこを読むと、「教えたいが自分は学習しないなどの矛盾した言動」そういうことがかいてあるのですかね？

まぁ、このあたりは、短い文章では伝え切れていないってことも、勘違いも、読み間違いもあるでしょうから、見なかったことにしときましょう。




>質問に一貫性がなさすぎ
一貫して、「ジャッジメント」について聞いてるのですけどね？


そのほかは、そもそも、単に私の現在のミッションなどについて説明しただけで、インドリさんがそれに反応しただけではないのですか？もっとも、誤解を生む書き方でないかというと、そうではないかもしれませんし、自分のミッションを書くのは思わせぶりだとなるかもしれません。親切で反応してくれたのかもしれませんし。私もコメントに反応しましたからね。これについてとやかくいっても始まらないのでもうやめましょう。


でも、本筋は何度か言ったように、


学習をしているなかで、または結果として、良い物ができたかどうかを判断する良い方法が無いか・・・
元記事は、独学向けに書かれたように見えたものですから。
そこが違うとなると、そもそも論になっちゃうのですけどね。


具体的に言うと、

オブジェクト結合度が低いかそうでないかをどうすれば判断できるのか
役割を明確に決めてシンプルに定義できているのかどうか
言語特性を考慮したオブジェクトを定義できているかどうか
といった（これは記事の引用です）事を判断することができるのか？
その判断する方法が（学習段階で）あるの？ということです。

実践しか無いとなれば、世の中の独学している人は・・・泣ける


もっとも、元記事のターゲットは、「実践が可能。多少なりとも実務の出来る環境がある人」と最後のほうでは読めなくもないので、そういうことならば、三位一体というより、実践も同時に行うってことで、「四位一体」ってなるのですかね。

別にＯＯに限らず、どのような方法論も実装も、実践込みでやったほうが良いなんて「あったりまえ」のこと過ぎて、あえて言うからには、本当は何か「別のコツ」をもっているのでしょう？と深読みしたわけですよ。ＭＳがよくやりますよね（ｗ）
そういう意味では、私がひっかかった？

>私は「考えた結果が正しいかをジャッジする方法」と聞い
>てるのに対し「自分で実践し、判断するしか無い」的な回
>答ですので、ここで、何か、インドリ流の「コツ」があるか
>とおもったんですけど、無いのかなぁ、残念。

そんなコツ持っていたら、本が一冊出版できるレベルですよｗ
一ブロガーにそこまで求めるのは酷ってもんじゃないでしょうか。

> うーん、どうも全然本筋と違う部分に反応されまくっちゃうので、困りました・・
>
だから、何度もはっきりと要点を聞いているのですが・・・

>
> .NET Frameworkのソースを読んで、関心するレベルって、インドリさんの中では、ＯＯ知らない人って位置づけなのでしょうか。そういわれるとMS本社の連中も泣くでしょうね。（.NET で作成されたソースと勘違いしたのかな？）まぁ、コードが読めるだけでしょっていっちゃうと、そうかもしれませんけどね。
>
コードが読めるとオブジェクト指向を実践できるとは大差があります。

> 勉強する予定が無い＝勉強するつもりがない、っとこれも勘違いしたのかな？
> 既に（それこそ実践込みで）勉強しまくって終わってるつもりなんですけど・・・C++が登場したときの話もしたし・・・伝わらなかったか・・・（一生勉強だとか禅問答的なことはおいてね）
>
だから、貴方が勉強するつもりがないことを何故他者へ勉強させようとするのかと聞いているのです。
貴方の言う事はかなり無理があります。

> >自身が分からない事を他者へ教える事は出来ません
> どこをどう読むと、ＯＯ知らないことになっちゃうのかな？そりゃＯＯに関する全てを網羅しているかといわれれば違うと自信もっていえますが。
>
知っていたら貴方が教えるでしょ？
どこをどう読んだらオブジェクト指向に熟練していると受け取れるのでしょうか・・・


> >オブジェクト指向を他者へ教えたいが自分は学習しないなどの矛盾した言動をとる限り
> どこを読むと、「教えたいが自分は学習しないなどの矛盾した言動」そういうことがかいてあるのですかね？
>
貴方は勉強しないと明言していますが？

> まぁ、このあたりは、短い文章では伝え切れていないってことも、勘違いも、読み間違いもあるでしょうから、見なかったことにしときましょう。
>
あのーそうやって私のコメントを読んでいないから話が通じないのだと思うのですが・・・


> >質問に一貫性がなさすぎ
> 一貫して、「ジャッジメント」について聞いてるのですけどね？
>
>
> そのほかは、そもそも、単に私の現在のミッションなどについて説明しただけで、インドリさんがそれに反応しただけではないのですか？もっとも、誤解を生む書き方でないかというと、そうではないかもしれませんし、自分のミッションを書くのは思わせぶりだとなるかもしれません。親切で反応してくれたのかもしれませんし。私もコメントに反応しましたからね。これについてとやかくいっても始まらないのでもうやめましょう。
>
単刀直入に書けばいいものをダラダラ書いているからこうなるのです。
本題以外のものというのであれば、何故貴方は本題以外の所に力を入れて書くのですか？
それからジャッジは何度も言っていますが、まだお分かりになっていないようですね・・・
自分で判断する自身がない人に独習できますか？

> 学習をしているなかで、または結果として、良い物ができたかどうかを判断する良い方法が無いか・・・
> 元記事は、独学向けに書かれたように見えたものですから。
> そこが違うとなると、そもそも論になっちゃうのですけどね。
>
だから、自分でオブジェクト指向の流れを体験する事につきるのです。
何度言えば分かってもらえるのでしょうか？
貴方が勉強する気がないのであればなおさら説明し辛いのですが・・・
その誰かが何ものか分からないのに、教えようがないといっているのですが、何時になったら分かってもらえますか？

>
> 具体的に言うと、
>
> オブジェクト結合度が低いかそうでないかをどうすれば判断できるのか
> 役割を明確に決めてシンプルに定義できているのかどうか
> 言語特性を考慮したオブジェクトを定義できているかどうか
> といった（これは記事の引用です）事を判断することができるのか？
> その判断する方法が（学習段階で）あるの？ということです。
>
再利用してみればわかります。

> 実践しか無いとなれば、世の中の独学している人は・・・泣ける
>
それが出来ない人には独習は出来ません。
それとも貴方は、オブジェクト指向に明確な正さがあると考えているのですか？
オブジェクトの正しさは無限です。
どれだけ上手くやったつもりでも、それ以上のオブジェクトを作ってしまう人が世界のどこかに居ます。

>
> もっとも、元記事のターゲットは、「実践が可能。多少なりとも実務の出来る環境がある人」と最後のほうでは読めなくもないので、そういうことならば、三位一体というより、実践も同時に行うってことで、「四位一体」ってなるのですかね。
>
なりません。
三位一体です。
勝手に一つ付け加えないで下さい。

> 別にＯＯに限らず、どのような方法論も実装も、実践込みでやったほうが良いなんて「あったりまえ」のこと過ぎて、あえて言うからには、本当は何か「別のコツ」をもっているのでしょう？と深読みしたわけですよ。ＭＳがよくやりますよね（ｗ）
> そういう意味では、私がひっかかった？
だから何度も言っているように、対象人物が明確でなく、どれだけのレベルを求めているのかわからない状態では答えようがありません。


うーん。私の話しをきいていませんね。
私の質問に答えてください。
いくらダラダラ書いても貴方がまともに答えないのであれば話しは前に進みません。

> >私は「考えた結果が正しいかをジャッジする方法」と聞い
> >てるのに対し「自分で実践し、判断するしか無い」的な回
> >答ですので、ここで、何か、インドリ流の「コツ」があるか
> >とおもったんですけど、無いのかなぁ、残念。
>
> そんなコツ持っていたら、本が一冊出版できるレベルですよｗ
> 一ブロガーにそこまで求めるのは酷ってもんじゃないでしょうか。

それがね、この方は対象となる人が明確でないので、多分「万人がオブジェクト指向を習得する方法」を聞いている様なのです。
オブジェクト指向は立場によって違うとり方があるという事をどうやら分かっていないようです。
万人にオブジェクト指向を極めさせられる方法があれば、とうの昔に本が出版されていますよね。
それに、正しいの基準がないので答えようがないのです。
大変困っています。

oumiさんとのズレは、彼が以下の事を分かっていないから生じているのだと思います。

【オブジェクトに正しさに関する絶対的な指標はない】
オブジェクトの正しさを数値化できれば苦労しません。
この記事にも書いているように、凝ればいいというものではありません。
ビジネス上の利益を考えて、経費と利益のバランスを取れるようにオブジェクトを作らねばなりません。
また、その様な本があるのならば誰もが飛びつくでしょう。

【独習と組織的学習は異なる】
独習するのと組織的に学習させるのとではかなり意味が異なります。
先ずそこが分かっていないから質問が曖昧なのだと思います。

【学習には個人差がある】
学習にも個人差がある事を考慮していないようです。
彼はよく分からない人の代わりに聞いていますが、本人ではないのでその人にあわして答えることが出来ません。
どういった人に教えるのかでオブジェクト指向の学習法も異なります。

【机上の空論】
実践を伴わないと机上の空論になる事をご存じないようです。
質問を読むに机上で「オブジェクト指向を極める？」ことを目指しているようですが、そんな方法は存在しません。

【目標を明確化すること】
人間の脳は目標を明確化することにより、学習効果が高まります。
ですから目標を明確化せねばなりません。
また、目標とするレベルに応じた学習法があります。

oumiさんにはこれらの事を分かってもらいたいです。
そうすれば、もっと具体的に質問して欲しいという意味がわかると思います。

自分の判断に自信が持てない人には【独習】はお勧めできません。
一人でするという事は自己判断が伴う事を意味します。
それが嫌ならば複数人で学習するしかないでしょう。
自分の判断に自信が持てない人が独習する時点で間違っていると私は思います。

>そんなコツ持っていたら、本が一冊出版できるレベルですよｗ
>一ブロガーにそこまで求めるのは酷ってもんじゃないでしょうか。

そのとおりでしょう。しかし、私は万人に通用する「何か」なんて聞いていないのです。元記事の抽象度合いに合わせて「で、どうやって判断するの？」って聞いただけ。
何度もいってますけどね。

>それがね、この方は対象となる人が明確でないので、多分「万人がオブジェクト指向を習得する方法」を聞いている様なのです。

自分でこれいっちゃったらまずいでしょう・・・
いや、ほんとうにこれ良いの？言っちゃって？
いったい元記事の学習法とは、誰に、どのようなレベルの人に、どうやって学ぶべきだということを発信しているのでしょう？万人にではないのですか？特定の人向けなんですか？（お前以外の誰かだとか言われると泣きます）

自分の学習法だといいながら、「書いてください」「してください」を連発しています。つまり、対象は不明ですが、人に「こうやって学習するんですよ」と進めているように読めますね？自分の学習方法の紹介とは趣が違うのではないですか？
ですから、「できたものはどうやって、判定するのですか？」
すごく単純な動機の質問なんですね。


５つの【】書きを私が理解していないということに対しては、単純に私の能力に対する侮蔑と受け取っておいて、ここで細かく書くのはやめておきましょう。
（内容が当たり前過ぎて何かを書く気にもならない内容ですので）



元記事はどう読んでも、そこいらの文献やらなんやらから集めただけの内容がほとんどにみえました。私が関心したのは、そのなかでも唯一インドリさんの考えが現れているなという部分です。
>もし貴方が一部のオブジェクト指向しか出来ない部署にいても、頭の中でオブジェクト指向分析・設計・プログラミングを行いましょう。そうする事によりオブジェクト指向能力が鍛えられます。

ここです。「考えるだけでも鍛えられる。」そのとおり。それは私も経験から肯定します。そうして、感心した上で、単純な質問をしただけなのに、


>> 私はこの「正しさのジャッジ」が、独学では不可能でネックになると思うのですが、何か良い方法はあるのでしょうか？
>> 回数をこなすといつか判るというときが来るとは思いますが、それでは、学び方として魅力のある方法とは思えませんし。

>実際にオブジェクトを再利用すればわかります。
>よいオブジェクトならば再利用しやすく、悪いオブジェクトの場合は再利用しにくいのです。
>やはり実体験を伴わないとオブジェクトに関する思考能力はUPしません。

これが回答ですか・・・
学習方法でもなんでもないじゃないですか・・・


そして、５つの【】書きによる、侮蔑・・・

ラーニング企業で教育コースをいくつも作ってきたのに・・
いくつかの企業に請われて、わざわざ無料でその企業向けの２日間のOO講座を作ったりしたりしてるのに・・
某大手メーカの○万人を教育するためにどうしようとか考えるミッションやってきているのに・・
いやー、まぁ、それでも「５つの【】書き」知らないっていわれるのか・・・
元記事に書いてないから、「できたものはどうやって、判定するのですか？」って聞いただけなのに・・・
おじさん、２０年以上もOOな世界で過ごしてきてこれ言われたら、悲しいよ（TT)


それともあれですか？
インドリさんわざとに、「できたものはどうやって、判定するのですか？」に対する明確な回答避けてますか？

それとも読み取れって事？「判定する方法は無い！」って。
私はないと思ってたんですけど、インドリさんなかなか無いって言わないですから。
何かあるのかと思ってたんですけど・・・遠まわしに遠まわしに「無い」いっているような感じをかもし出すだけで・・・決め付けて誤解しちゃうとまずいですからね、ウン。


はっきりと「判定する方法は無い！」っていってくれれば、なんだそうか、じゃぁやっぱり、モデルファーストで勉強するような工夫が必要だね(^^)bで終わったのですけどね・・・つまり、結果を後からジャッジできるように構成されたモデルを使って、設計〜実装まで通すって事ね。その後で実践が有効ってね。
教育機関のテキストは、独習できるようにそうなってるものが多いですね。まぁインドリ氏には言わずもがなですか。


いや今回はちょっと怒っています。
どうも、そのへんの難癖つけるブロガーと一緒くたにされてるような気がする・・

一向に話しが通じないですね。
組織がどうのダラダラ言った上でこれですか・・・
組織と個人では学習法が異なると何度言えば分かるのでしょうか？
私がこの記事で言っているのは個人の学習法です。
ですから何度も組織についてなのかと聞いているのですが・・・

そして、正しさの基準については「再利用するば分かる」と何度言えば分かるのでしょうか？
再利用し難いという事は確実にオブジェクト化に失敗していますし、更なる良いオブジェクトを作り出すには創意工夫が必要です。
独習なのですから自分でよくしようとする精神が必要なのです。
それを無視するから、「自分で判断できない人は独習できない」と言っているのですが意味わかっていますか？
誰かのお墨付きが欲しいのであれば独習は無理です。

私としてはそれを踏まえてより深いことを聞きたいようなので、状況に応じた最適化した答えを返そうと思って、曖昧な質問について粘り強く聞いていたのにその態度ですか・・・
それが人に物を尋ねる時の態度でしょうか？
貴方の場合、先ず社会人として如何なものかと思います。

当たり前の事なのでくどくどと説明しませんでしたが、分かっていないようなので書きます。
次の回で書いているオブジェクトの再利用とは違う側面の事なのですが、オブジェクト指向はコード等の再利用が重要視されています。
今回は一番簡単なコードの再利用について述べます。
そのオブジェクトを他のプロジェクトにそのまま持っていけるのかが再利用の高低を表しています。
そのオブジェクトが、他のプロジェクトで使用する際に修正せねばならないのであれば再利用出来ていません。
そして、再利用するに当たって多くのオブジェクトを連れて行かねばならない時は結合度が高く、オブジェクトの再利用度が低いという事になります。
そして、オブジェクトの修正をする際に、他のオブジェクトも修正せねばならないのであれば、それはカプセル化がちゃんとなされていない事を意味します。
そういった事は「再利用すれば嫌でも分かります」
もしどうしても分からないというのであれば、それはプログラミングが分からないといっているのと同じで、プログラミングの基礎から勉強する必要があるでしょう。

分析の正しさについては、「システムの完成度」で如実に現れます。
分析が見当違いであれば、そのシステムは使い辛く、システムの要求を満たしていないでしょう。
そして、満たしている場合でも、より少ない期間でそれが実現できるように考えるとよいでしょう。
また、その分析結果に共通部分がないかを考えるとより深く学べます。

設計については、「オブジェクトの使いやすさ」でその良し悪しがよく分かります。
実装しやすく、オブジェクトが使いやすいならば設計は成功です。
そして、その設計がオブジェクトデザインの領域にまで高められるのであれば大成功といえるでしょう。

これらは文章でダラダラと理屈を述べられるよりも、自分でやってみるとよく分かります。
論より証拠です。
情報処理技術は工学なのですから、とにかく実践しましょう。

「ジャッジする方法はある！」ってことじゃないですか・・・


>今回は一番簡単なコードの再利用について述べます。
>そのオブジェクトを他のプロジェクトにそのまま持っていけるのかが再利用の高低を表しています。
>そのオブジェクトが、他のプロジェクトで使用する際に修正せねばならないのであれば再利用出来ていません。
>そして、再利用するに当たって多くのオブジェクトを連れて行かねばならない時は結合度が高く、オブジェクトの再利用度が低いという事になります。
>そして、オブジェクトの修正をする際に、他のオブジェクトも修正せねばならないのであれば、それはカプセル化がちゃんとなされていない事を意味します。
>そういった事は「再利用すれば嫌でも分かります」
>もしどうしても分からないというのであれば、それはプログラミングが分からないといっているのと同じで、プログラミングの基礎から勉強する必要があるでしょう。

このように、単純に「再利用すればわかる」ではなく、再利用という観点で見たときに、見るそのポイントを示唆することが、まさに学習の結果判定につながる話だと思います。今回のコメントは、非常にしっくりきました。これは、たまたまかインドリさんの配慮によるものかは判りませんが、万人向けに整理されていると言ってよいのではないですか？

「で、どうやって判定するの？」という質問に対して、「再利用という観点からジャッジする方法」といえるのではないですか？。

・そのオブジェクトを他のプロジェクト（他のアプリケーション）にそのまま持っていけるのか
・再利用するに当たって多くのオブジェクトを連れて行かねばならないかどうか
・オブジェクトの修正をする際に、他のオブジェクトも修正せねばならないかどうか
平易な言葉で誰にもわかりやすいですね。
そして、このように再利用という観点からの判定では「絶対よいオブジェクト」があるってことじゃないですか。実際ありますから、正しい事だと思いますよ。
やっとしっくりくる内容になってきました。

再利用性という言葉では伝わりにくい事が、このように整理されると非常によく伝わります。つまりインドリさんの考えが良く伝わるという事です。実際伝わってきた気がします。
現実問題では、「別プロジェクトにもっていけない」とか色々ありますけど、ここでは学習法についてなので、これで問題ないと感じます。

そして、学習法は、なんども繰り返せとかって言い方になっているようですが、真意は単純な言葉通りの意味ではなくて、例えば、
「前回作成したものを使って、再利用する事（物）という反復練習する」とかそんなことなんじゃないですか？
確かに、このような色々なことを「いちいち」そして「短い言葉」で言おうとすると、「実践あるのみ」とか「自分で考えられないやつはだめ」的になってしまうのかもしれません。なので件の質問がでてきたわけですけどね。

>オブジェクト指向に熟練するには実践が一番
こういった、まとめも、前提としてどのように考えながらやるって事など、つまり、学習【方法】をもう少し細かく示唆することで、ちゃんと真意が伝わるのではないでしょうか。


たくさんの事を１つの記事に書こうとして、細部まで言えていないってことだけだったのかもしれません。当然、読みやすい量っていうものもありますしね。
ですが、今回のコメントのようなことを、補足などとして追記していくと、インドリ流になって良い記事になると思いますよ。
（まぁ大きなお世話かもしれませんが。）

>これらは文章でダラダラと理屈を述べられるよりも、自分でやってみるとよく分かります。
ダラダラではなくて、「再利用について」にあるように、整理されていて、なおかつ、わかりやすい平易な言葉で書かれているっていうことが、これから学習しようと思っている人とって非常に有益なのだと思います。（これも大きなお世話かもしれませんが。）

もっとも、別の記事で何か書かれる予定だったということのようですから、質問自体、もう少し待っていれば、必要の無かった質問だったのかもしれませんね。

ちょっとむかついた部分もありましたけど、質問に対する回答が、ある観点から出た！ということで、私はこれで満足しました。インドリさんはフラストレーションたまってるかもしれませんが・・
これで、いったんコメント控えるようにします。
お騒がせしました。

インドリさんがつらつらと語っている事は、オブジェクト指向の基礎、またはオブジェクト指向を学習する上での姿勢としては間違っていないのかもしれません。

ただ、それらは本当に基本的なことであり「学習法」と呼ぶほどのシロモノではないと思います。

タイトルからして「オブジェクト指向との付き合い方。」と銘打っているので、何か余程のネタが書かれているのかと思い読んだのですが、杓子定規な根性論が展開されているだけだったので残念です。

結局、オブジェクト指向を身に付けるにはトライ&エラーでひたすら頑張らなくちゃいけないって事ですね。
うん、当り前だのクラッカー

> 「ジャッジする方法はある！」ってことじゃないですか・・・

プログラミングする人ならば分かると思って省略していたのが悪かったのですね。
それと、お察しの通りまた別に書こうとしていた所もありました。
なにはともあれ、分かってくれてよかった。

> インドリさんがつらつらと語っている事は、オブジェクト指向の基礎、またはオブジェクト指向を学習する上での姿勢としては間違っていないのかもしれません。
>
> ただ、それらは本当に基本的なことであり「学習法」と呼ぶほどのシロモノではないと思います。
>
> タイトルからして「オブジェクト指向との付き合い方。」と銘打っているので、何か余程のネタが書かれているのかと思い読んだのですが、杓子定規な根性論が展開されているだけだったので残念です。
>
> 結局、オブジェクト指向を身に付けるにはトライ&エラーでひたすら頑張らなくちゃいけないって事ですね。
> うん、当り前だのクラッカー

う〜ん、実践を通して分かった学習ポイントとかもちりばめてかいているんだけどな・・・
これ知っているのと知らないのでは天と地程の差があります。
ですから根性論ではないです。
それに、トライ＆エラーを繰り返さずに技術力はUPしません。
オブジェクト指向を極めるには実践しかありません。
情報処理技術は工学なのです。

トラックバックURL

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