私はかなり前からOOPを研究していて、理論をよく理解しています。私はOOPに関するHeadFirstの本を読みましたが、それは多くの理論を補強しましたが、ケーススタディはやや些細なものであることがわかりました。
私は毎日OOPの原則をコードに適用していることに気づきましたが、それらを正しく適用しているかどうかはわかりません。コードを見て、継承を適切に使用しているかどうか、オブジェクトが十分にまとまっているかどうかなどを知ることができるようになる必要があります。
確かなOOPスキルを開発するための次のステップを踏み出すための良い推奨事項（本、オンラインガイド、ブログ、ウォークスルーなど）はありますか？
私は主に.NET（ビジュアルベーシック）で作業していますが、さまざまなプラットフォームを組み込んだ提案を歓迎します。
Martin Fowlerによるリファクタリングを読んで、それを自分の作品に適用してください。
不適切に構築されたクラスを検出する方法、さらに重要なことに、それらを修正する方法を説明する、ソフトウェアコードのさまざまな悪臭のある特性について説明します。
デザインパターンを調べることを検討してください。エンタープライズアプリケーションでは一般的に使用されていないようですが（エンタープライズコードに埋め込まれているよりもAPIやフレームワークで一般的に使用されているのを見てきました）、多くの状況でソフトウェアをよりシンプルまたは堅牢にするために適用できます。開発者だけがそれらを適用する方法を知っていました。
重要なのは、最初にデザインパターンを理解してから、経験を積んでそれらを適用する方法を学ぶことです。
コンセプトを非常に簡単に教えるデザインパターンに関するHeadFirstの本がありますが、デザインパターンを詳細にカバーする本が必要な場合は、基本的にデザインパターンを主流にしたGangofFourデザインパターンの本をチェックしてください。トピックが取り上げられるたびに参照されます。
デザインパターンは、ほとんどすべてのオブジェクト指向言語である程度適用できますが、場合によっては、過剰または過剰なエンジニアリングになる可能性があります。
編集：
私も追加したいので、CodeComplete2という本をチェックしてください。これは、ソフトウェア開発の世界で非常に影響力のある本です。それは多くの異なる概念と理論をカバーしています。私はそれを読むたびに何か新しいことを学びます。半年から1年ごとに読んでみると、読み直すだけでプログラマーが上手になるという別の視点から見てもらえる、とてもいい本です。どれだけ知っていると思っても、この本はあなたが本当に知っていることがどれだけ少ないかを実感させるでしょう。本当に素晴らしい本です。私はあなたがこの本をどれだけ所有すべきかを強調することはできません。
あなたがすでに基本を持っているなら、私は経験だけがあなたをさらに前進させると信じています。原則を正しく適用しているかどうかはわかりませんが、正しい方法は1つではありません。今日書いたコードは、6か月後に見て、なぜそのように書いたのか不思議に思うでしょう。おそらく、より良い、よりクリーンな方法を知っているでしょう。また、10年経っても、新しいテクニックやコツを学ぶことができることを保証します。それについてあまり心配しないでください、それは来るでしょう、あなたができる限り多くを読んで、そしてあなたが読んだものを小さな塊で適用しようとします。
私は現在、次の本を半分読んでいます。
http://www.amazon.com/Applying-UML-Patterns-Introduction-Object-Oriented/dp/0131489062
コードに飛び込む前に、適切に形成された反復的な設計戦略を起草および適用するための実際のプロ級の実用的なアプローチを学習するという点で、 この本を強くお勧めすることはできません.
私も「Head First」の本を読んで、それを読んだ方がはるかに良いと感じました。
実業界で数年間の経験を積んだ後、私は今、クレイグ・ラーマンの本を読んでいます。この本は、私にとって完璧な「次のステップ」であると推奨しています。
UML 表記について肯定的な感情を持っているか否定的な感情を持っているかに関係なく、本 (ISBN 0131489062) を購入する決定に影響を与えないようにしてください。
タイトルの「UML」の隆起は誤解を招きます。著者は UML 表記法を使用して説明していますが、これらの説明は関連する設計の議論に非常にうまく織り込まれており、この本がつまらない UML 仕様のように読まれることは決してありません。
実際、本から直接引用したのは次のとおりです。
重要なのは、オブジェクトをどのように考えて設計するかを知ることです。これは、UML 表記法を知ることとは非常に異なる、より価値のあるスキルです。ダイアグラムを描くとき、重要な質問に答える必要があります: オブジェクトの責任は何ですか? それは誰と協力していますか？どのような設計パターンを適用する必要がありますか? UML 1.4 と 2.0 の違いを知るよりもはるかに重要です!
この本は、リード アーキテクトやプロジェクト マネージャーに「話しかけている」ように見えることがあります。私が言いたいのは、読者がソフトウェア プロジェクトの計画と方向性を大幅に制御できることを前提としているということです。
とはいえ、あなたが会社のプロジェクトや製品のごく一部しか担当していない場合でも、私はこの本をお勧めし、本書のアドバイスを「縮小」してプロジェクトの一部に適用することをお勧めします。
私のOOPエピファニーは、ずっと前のGradyBoochの本から来ました。突然、オブジェクトが優れている理由に気づきました。
ポリモーフィズムはクールですが、カプセル化はオブジェクトがクールである理由の75％です。これは一種のインターフェースのようなものです。ボタンは表示されますが、配線は表示されません。オブジェクトの前は、最も訓練されたコーダーだけが、他の人の手順の内部ビットから汚れた指を遠ざけていました（これは「構造化プログラミング」と呼ばれていました）。
オブジェクトは正しいことをするのを簡単にします。継承とポリモーフィズムは小さなボーナスです。
オブジェクトについて学ぶ1つの方法は、他の人のコードを読むことです。Delphi VCLフレームワークのソースコードを読んで、多くのことを学びました。Javaのドキュメントを見るだけでも、単一のオブジェクトクラスが何をすべきか、そしてそれが他のオブジェクトによって使用されるようにどのように設計されているかを理解するのに役立ちます。
独自のプロジェクトを開始し、独自のクラスをサブクラス化する場合は注意が必要です。保護されたメソッドをすべて置き換えるのではなく、プロセスの1つだけをオーバーライドできるように、戻っていくつかの保護されたメソッドを分割する必要があります。抽象関数を呼び出して、祖先が子孫とどのように通信するかを確認します。言い換えれば、多くの間違いを犯し、それらから学びに行きます。
楽しみ！
VB6 で非常にオブジェクト指向の問題 (SQL ステートメントを動的かつ再帰的に構築する) を実装しようとしたときに、ひらめきが起こりました。ポリモーフィズムまたは継承を理解する最善の方法は、それが必要であり、使用できないことです。
率直に言って、情報の隠蔽に関する古い David Parnas の論文を読み直すと、正しい心の状態にたどり着くことができます。ケーススタディは直接適用できない場合がありますが、それらからいくつかの有用な一般化を得ることができるはずです.
間違いなくあなたを助ける1つのことは、有名で尊敬されているオープンソースプロジェクトに取り組んでいることです。ソースコードを掘り下げて、物事がどのように行われるかを確認するか、いくつかの追加/変更を試みてください。ほとんどの問題に対して1つのスタイルまたは1つの正しい答えはありませんが、いくつかのプロジェクトを見ると、物事がどのように行われるかについての広い視野を得ることができます。そこから、独自のスタイルの開発を開始し、その過程でオープンソースに貢献できることを願っています。
OOソリューションの実装を試みて失敗する必要があると思います。それはとにかく私がそれをした方法です。私が失敗したということは、実用的なソリューションを提供する一方で、臭いコードを書くことになってしまうということです。それが書かれた後、あなたは物事が完全に正しく感じられなかったところの感触を得るでしょう。あなたはいくつかのエピファニーを持っているかもしれません、そして/またはあなたは他のプログラマーからのより滑らかな解決策を探しに行くかもしれません。間違いなく、誤って標準のデザインパターンのバリエーションを実装することになります。後から考えると、ライトがクリックされ（ああ！それが訪問者の目的です）、理解が加速します。
他の人が言っているように、私はいくつかの良いOOオープンソースコードを介してツールを作成することは良い考えだと思います。それで、あなたの仕事を批評することをいとわないであろうより経験豊富なプログラマーと協力しています。しかし、理解は行うことによってもたらされます。
しばらくの間、Smalltalk の読み取り (および書き込み) を試してみてください。Squeak は、(Java や .net とは異なり) 完全なオブジェクト指向環境の能力を示す無料の実装です。すべてのライブラリ コード ソースが含まれています。言語自体は信じられないほど単純です。java と c# は、1980 年以来 Smalltalk によく知られている機能をゆっくりと追加していることがわかります。
Tortoise HGは非常によく設計されたオブジェクト指向オープン ソース ソフトウェア (Python で記述) です。
基本をすでに理解している場合は、完全なオブジェクト指向言語でゼロから何かを構築することは、OOP ソフトウェア アーキテクチャを完全に理解するための良いステップになります。Python を知らない場合は、Python Essential Reference を参照すると、数日から 1 週間で完全に言語を理解できます。
言語を理解したら、上記のソフトウェアに目を通してください。あらゆる種類のひらめきが得られるでしょう。
基本的に何かを完全に理解するには、少なくとも 1 レベル上と 1 レベル下の抽象化レベルについて十分な知識が必要です。OO の場合、OO の上のレイヤーとしてデザイン パターンを挙げている人もいます。これは、OO がなぜ便利なのかを説明するのに大いに役立ちます。
OO の下のレイヤーに関しては、高階関数/遅延バインディングをしばらく試してみて、これらの比較的単純な構造がどのように使用されるかを感じてみてください。また、OO が内部 (vtables など) でどのように実装されているか、純粋な C でどのように実行できるかを理解するようにしてください。高階関数と遅延バインディングを使用する価値を理解すると、OO が関連する一連の関数とそれらが操作するデータを渡すための便利な構文です。