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

最近オブジェクト指向についての質問がよく来ますので、私が考えるオブジェクト指向の学習法などを囀ります。今まで私は何度かオブジェクト指向ネタを書いております。最初にそれを読んでください。
ネタつつき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の設計や、様々なインタフェースの設計や、データアクセス層の設計だけだとしても、ＯＯでしょといわれると、まぁそりゃそうだけどってなりますが・・・

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


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

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

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

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

このコメントは管理者の承認待ちです

トラックバックURL

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