オブジェクト指向プログラミングを実践するには？
私は常に手続き型言語でプログラミングしてきましたが、現在はオブジェクト指向に向かっています。私が直面した主な問題は、オブジェクト指向を効果的な方法で練習する方法が見当たらないことです。私のポイントを説明します。私がPHPとCを学んだとき、それは実践するのが非常に簡単でした：それは単に何かを選択し、そのことのアルゴリズムについて考えることの問題でした。
PHPたとえば、次のように考えて考える必要があります。「まあ、ただ練習するために、人々が製品を追加できる管理領域を持つ1つのアプリケーションを作成しましょう」。これはかなり簡単でした。 、あるユーザーを登録し、ユーザーをログインし、製品を追加するアルゴリズムを考えることでした。これらをPHPの機能と組み合わせることで、実践する良い方法でした。
さて、オブジェクト指向では、さらに多くのものがあります。アルゴリズムについて考えるだけでなく、要件をより深く分析し、ユースケースを記述し、クラス図、プロパティ、メソッドを理解し、依存関係の注入などを設定します。
要点は、私がオブジェクト指向を学んできた方法では、優れたデザインが非常に重要であるように思われる一方で、手続き型言語では1つのあいまいなアイデアで十分でした。私はnot手続き型言語でデザインなしでgoodソフトウェアを書くことができると言っています、それを実践するためだけです実現可能ですが、オブジェクト指向では、実践する場合でも、優れたデザインなしでは実現できないようです。
これは問題のようです。なぜなら、練習するたびに多くの要件、ユースケースなどを理解する必要がある場合、これはオブジェクト指向を向上させるための良い方法にはならないようです。練習するたびに、アプリの全体的なアイデアを1つにまとめることができます。
そのため、オブジェクト指向を練習する良い方法は何ですか？
さて、オブジェクト指向では、さらに多くのものがあります。
いいえ、必要ありません...
アルゴリズムについて考えるだけでなく、要件をより深く分析し、ユースケースを記述し、クラス図、プロパティ、メソッドを理解し、依存関係の注入などを設定します。
オブジェクト指向プログラミングを実践するためにこれらのことは必要ありません。
これは非常に簡単でした。あるユーザーを登録し、ユーザーにログインし、製品を追加するアルゴリズムを考えるだけでした。
すべてのオブジェクト指向プログラミングは、これらの手順を実行するためのアルゴリズムを考えるのではなく、これらの手順を実行するために必要なオブジェクト、必要な機能、そのために必要な状態、および公開するインターフェイスの種類について考えます。ユーザーに。 手続き型プログラミングで行う必要があるように
唯一の違いは、必要な機能とその機能に焦点を合わせるのではなく、機能と状態を責任にグループ化する方法と、それらの責任がどのように相互作用するかに焦点を当てることです。
練習するには？手続き型プログラミングを実践するのと同じ方法：問題を選び、クラスのバンドルを使用して問題を解決します。それがどのように失敗したかを理解し、学んだ教訓で繰り返します。
良い質問。もちろん、あなたが言っていることは、OOPを実践することは、実際にはこれらすべてのこと（要件分析、ユースケース、設計パターンなど）を実践することを意味します）です。 。
私のアドバイスは、2つのことを念頭に置いて練習セッションを開始することです： テスト駆動型開発 と 単一責任の原則 。
次に、PHP/Cの場合と同じように始めます。アイデアを思いついて、何が必要かを考え、これらを次々に実装します。ただし、テスト（最初は適切なインターフェイスを定義する必要があります。そうしないとテスト性がすぐに低下するため）から開始する必要があり、TDDは赤と緑のリファクタリングサイクルを意味することに注意してください。言い換えると、ごくわずかな機能があり、それが機能すると、最初から作成しなかった場合（そうしない場合）、適切なOO設計を取得するためにリファクタリングします。
このリファクタリング手順を実行するときは、常にSRPを思い出してください。オブジェクトに2番目の責任を追加した場合は、新しい何かを作成するときです。
このように開発する場合は、最終的なソリューションが最初のソリューションとは大きく異なることに注意する必要があります。学習曲線もかなり急になります。たとえば、Factoryパターンが何であるかを学習するのではなく、さまざまな方法でクラスのインスタンスを作成する何かの必要性を認識します。したがって、オブジェクト指向のデザインパターンについてまったく聞いたことがない場合は、それらを並行して少し読むことをお勧めします。
OOPから始めたばかりの場合は、実際のシステムについてを見て、オブジェクトとは何か、オブジェクト間の関係とは何かを検討することで、オフラインで「練習」できます。それらがサポートする可能性のあるメソッド/インターフェース、およびクラス階層でインスタンス化されたオブジェクトのコレクションとしてそれらをどのように表現するか、オブジェクト所有権関係はどのようになるかなど（注：で「アルゴリズム」という言葉は触れませんまったく）。何かをコーディングすることを考える前に、ダイアグラムのlotsを描画します（UMLなどを少し学んでください）。
これは IS-AとHAS-A の関係をよりよく理解するのに役立ちます。これは、OOPの設計でおそらく最も重要な単一の分類です（そしてそれはまだ、多くの熟練したOOP言語プログラマーが苦労しているもののようです。）あなたがIS-A/HAS-Aをマスターしている場合、 IS-IMPLEMENTED-IN-TERMSもあります。 -OF （IS-KIND-OF-Aとして記述されていることも確認しました：^）
真剣に、次のスーパーマーケットへの旅行、誰かがあなたにOOP場所のシミュレーションを書く仕事を与えたと想像してください...
私のCの時代（過去のはるか昔）から覚えていることですが、以前は機能と手順を責任に基づいてさまざまなファイルに分けていました。それが完璧であるとは言い切れませんが、実際にオブジェクト指向言語でプログラミングを始めたときの良い出発点でした。したがって、おそらく、ファイルをオブジェクトに変換することから始めることができます。
OOPに関する限り、それは本当に練習と改善のための努力がすべてです。めったに誰もがゼロからそれを正しく行うことはほとんどありません。したがって、反復はプロジェクトのライフサイクル全体で発生します。
1990年代の Peter Coadが行った のように、いくつかの用語 オブジェクト指向分析 および オブジェクト指向設計 を追加してみましょう。
これらを合わせて ソフトウェアエンジニアリング分野のOOAD は、コードの作成およびテストの時点でプログラマをサポートする（正しく行われる）ことができます。オブジェクト指向プログラミングは、適切なレベルの粒度、プログラミング言語の機能を上手に使用して、プロジェクトレベルで指定された機能目標と設計要件を満たすことができます。
時にはそれが一人のプロジェクトであり、そしてあなたはすべての帽子を着用しなければならない（しかし必ずしもすべて同時にではない）。私は自分の個人プロジェクト（フランクの推奨事項を参照）のテスト駆動開発の大ファンですが、それはオブジェクト指向ソフトウェア開発だけに関係しているわけではありません。
チームプロジェクトでは、責任を適切に分割することが、実装を成功させる鍵となります。オブジェクト指向のデザインパターンを上手に使用すると、分析、データフィード、およびビジネスロジックに必要な目に見えるインターフェースを制限して、使用可能なフレームワークを共有できるため、チームの理解に役立ちます。
「まあ、ただ練習するために、人々が製品を追加できる管理領域を持つ1つのアプリケーションを作成しましょう。」これは非常に簡単で、一部のユーザーを登録し、ユーザーにログインし、製品を追加するアルゴリズムを考えるだけでした。
今回はユーザーオブジェクトと製品オブジェクトだけで同じことをしませんか？また、手続き型とOOの両方をサポートする言語を使用している場合は、ファイルオブジェクトなどの手続き型標準ライブラリに基づいてオブジェクトを実装することもできます。