一般的なプログラミング パラダイムまたはプログラミング スタイルには、手続き型プログラミング、オブジェクト指向プログラミング、関数型プログラミングの 3 つがあり、オブジェクト指向プログラミングはその中で最も主流のプログラミング パラダイムです。
現在、私が学んだ Java に代表されるように、ほとんどのプログラミング言語はオブジェクト指向プログラミング言語であり、ほとんどのソフトウェアはオブジェクト指向プログラミングのプログラミング パラダイムに基づいて開発されています。
1. オブジェクト指向とは何ですか? プロセス指向とは何ですか?
オブジェクト指向とは何ですか?
オブジェクト指向プログラミングは、プログラミングのパラダイムまたはスタイルです。コードを編成するための基本単位としてクラスまたはオブジェクトを使用し、カプセル化、抽象化、継承、ポリモーフィズムの 4 つの特性をコードの設計と実装の基礎として使用します。
オブジェクト指向プログラミング言語とは、クラスやオブジェクトの構文機構をサポートし、オブジェクト指向プログラミングの4大特徴（カプセル化、抽象化、継承、ポリモーフィズム）を容易に実現できる既成の構文機構を備えたプログラミング言語です。 。
プロセス指向とは何ですか?
手続き指向プログラミングもプログラミングのパラダイムまたはスタイルです。コードを編成する基本単位としてプロセス (メソッド、関数、操作として理解できる) を使用し、主な機能としてデータ (メンバー変数、属性として理解できる) とメソッドを分離します。
プロセス指向スタイルは、一連の順次実行メソッドを結合することによってデータを操作して関数を完成させる手続き型プログラミング スタイルです。手続き型プログラミング言語は、何よりもまずプログラミング言語です。
その最大の特徴は、クラスとオブジェクトという 2 つの文法概念をサポートしておらず、豊富なオブジェクト指向プログラミング機能 (継承、ポリモーフィズム、カプセル化など) をサポートしておらず、プロセス指向プログラミングのみをサポートしていることです。
実際、実際的な観点から見ると、オブジェクト指向とは、オブジェクトを使用して物事の変化を操作することを意味します。オブジェクトを操作することで神の視点を使用してタスクを完了できますが、プロセス指向は操作のプロセスです。視点として自分自身を使用します。そして操作のプロセス。
2. プロセス指向プログラミングと比較したオブジェクト指向プログラミングの利点は何ですか?
- オブジェクト指向プログラミングには、手続き型プログラミングに対する主な利点が 3 つあります。大規模で複雑なプログラムの開発では、プログラムの処理の流れは一本の幹線ではなく、複雑なネットワーク構造になります。
- オブジェクト指向プログラミングは、手続き型プログラミングよりもこの複雑な種類のプログラム開発をうまく処理できます。オブジェクト指向プログラミングには、手続き型プログラミングよりも豊富な機能 (カプセル化、抽象化、継承、ポリモーフィズム) があります。
- これらの機能を使用して作成されたコードは、拡張、再利用、保守が容易になります。プログラミング言語がマシンを扱う方法の進化から、オブジェクト指向プログラミング言語は手続き型プログラミング言語よりも人間的で、より高度で、よりインテリジェントであると結論付けることができます。
3. オブジェクト指向のように見えても、実際にはプロセス指向であるコード設計はどれですか?
オブジェクト指向プログラミング言語を使用してソフトウェアを開発する場合、手続き型スタイルでコードを記述することがあります。それらの中には、意図的なものもあって何も問題はありませんが、その他のものは意図的ではなく、コードの品質に影響します。
- getter メソッドと setter メソッドの悪用
オブジェクト指向の機能の一つであるカプセル化が必須であることはわかっていますが、lombokの@Dataのようなアノテーションを使えば、メンバ変数をすべて追加することと同じになります。
setget メソッドを使用する理由は、一般に、将来使用するために事前に定義しておくと、クラスがより使いやすくなり、これらのゲッターが使用されない場合でも、
setter メソッドも、定義上、害はありません。実際、これはすべてのメンバー変数を完全に公開し、自由に変更できるため、オブジェクト指向のカプセル化の特性に違反します。
想像してみてください、すべての set メソッド、メンバー変数を開くこと、および public を追加することの違いは何でしょうか? オブジェクト指向のカプセル化の定義は次のとおりです: アクセス許可制御によって内部データを隠し、
外部の世界は、クラスによって提供される制限されたインターフェイスを通じてのみ内部データにアクセスし、変更できます。したがって、公開すべきではないセッター メソッドを公開することは、明らかにオブジェクト指向のカプセル化に違反します。
特性。データへのアクセス制御はなく、どのコードでもデータを自由に変更でき、コードはプロセス指向のプログラミング スタイルに退化します。
- グローバル変数とグローバル メソッドの悪用
オブジェクト指向プログラミングでは、共通グローバル変数にはシングルトン クラス オブジェクト、静的メンバー変数、定数などが含まれ、共通グローバル メソッドには静的メソッドが含まれます。シングルトンクラスオブジェクト
グローバル コードにはコピーが 1 つだけあるため、グローバル変数と同等です。静的メンバー変数はクラス上のデータに属し、インスタンス化されたすべてのオブジェクトによって共有されます。
ある程度グローバル変数にも相当します。定数は非常に一般的なグローバル変数であり、たとえば、一部のコードの構成パラメータは通常、定数に設定されます。
それを Constants クラスに入れます。静的メソッドは通常、静的変数または外部データを操作するために使用されます。私たちがよく使用するさまざまな Utils クラスを考えることができます。
内部のメソッドは通常、オブジェクトを作成せずに直接使用できる静的メソッドとして定義されます。では、tool クラスだけを使ってみましょう
静的メソッド、一部の構成クラスでは変数を個別に使用でき、メソッドをデータから分離し、典型的なプロセス指向のスタイルであるカプセル化機能を破棄できます。
オブジェクトがまったく使用できないというのは本当ですか? 重要なことは、悪用できないということです。設定クラスをより詳細にする必要があり、いくつかの設定クラスに直接配置するのが最善です。
直接使用してください。たとえば、RedisConfig クラスは Redis 構成に関連する定数を使用し、これらの定数を RedisConfig で直接定義します。
クラス設計の凝集性とコードの再利用性が向上しました。Uitls のようなツールに関しては、ソフトウェア開発に非常に役立ち、コードの再利用の問題を解決できます。
したがって、Utils クラスをまったく使用してはいけないという意味ではなく、乱用は極力避け、むやみに Utils クラスを定義しないでください。まだ感じていますか
このような Utils クラスを定義することは確かに必要なので、大胆に定義してください。オブジェクト指向プログラミングであっても、指向性を完全に排除するわけではないため、
手続き型スタイルのコード。良いコードを書くのに役立つ限り、適度に使用することができます。
- データとメソッドを分離するクラスを定義する
こんな明らかにプロセス指向のコードを誰が書くだろうか、と思われるかもしれません。実際、MVC の 3 層構造に基づいて Web を実行している場合は、
バックエンド開発では、この種のコードを毎日作成することがあります。フロントエンドとバックエンドの分離後、3 層構造はバックエンド開発中にわずかに調整され、次のように分割されます。
コントローラー層、サービス層、リポジトリ層。コントローラー層はフロントエンド呼び出しにインターフェイスを公開する役割を果たし、サービス層はコアのビジネス ロジックを担当します。
リポジトリ層はデータの読み取りと書き込みを担当します。各レイヤーで、対応する VO (ビュー オブジェクト)、BO (ビジネス オブジェクト)、およびエンティティを定義します。
通常、VO、BO、Entityにはデータのみが定義されており、メソッドは定義されておらず、これらのデータを操作するためのビジネスロジックはすべて対応するControllerクラスに定義されており、
サービスクラス、リポジトリクラス。これは典型的な手続き指向のプログラミング スタイルです。実は、この開発モデルは貧血モデルベースの開発モデルと呼ばれています。
これは、現在私たちが使用している Web プロジェクトで非常に一般的に使用されている開発モデルでもあります。
4. オブジェクト指向プログラミングでは、プロセス指向のコードを記述するのが簡単なのはなぜですか?
人生では、タスクを完了するとき、通常、最初に何をするか、次に何をするか、一連のステップを段階的に実行する方法について考えます。
操作を実行し、最終的にタスク全体を完了します。プロセス指向のプログラミング スタイルは、人々のプロセス指向の考え方とまったく一致しています。オブジェクト指向プログラミング スタイルはその逆です。それは底です
上向きに考えてください。最初にタスクを実行プロセスに従って分解するのではなく、タスクを 1 つずつ小さなモジュール (つまりクラス) に変換し、クラス間の接続を設計します。
インタラクションを行い、最後にプロセスに従ってクラスを組み立ててタスク全体を完了します。前のレッスンで述べたように、この思考経路は複雑なプログラムの開発により適していますが、そうではありません。
それは人間の思考習慣とは特に一致しません。さらに、オブジェクト指向プログラミングは手続き型プログラミングよりも困難です。オブジェクト指向プログラミングでは、依然としてクラス設計が非常に必要です
スキルには、ある程度のデザイン経験が必要です。適切なデータとメソッドをクラスにカプセル化する方法、クラス間の関係をどのように設計するか、クラス間の関係をどのように設計するかを考える必要があります。
インタラクションやその他多くのデザイン上の問題。したがって、これら 2 つの理由に基づいて、多くのエンジニアは、開発プロセス中にあまり考える必要のない方法で要件を実装することを好みます。
プロセス指向スタイルでコードを書かずにはいられません。要約すると、私たちは常に慣れ親しんだ方法で考えるということになります。
自分の視点で何かを実行する、プロセス重視というのは私たちの考え方と似ています。
5. プロセス指向プログラミングは使用できませんか?
実際、プロセス指向はオブジェクト指向の基礎であると考えることができます。実際には、各メソッドの実行がプロセスであるため、プロセス指向ではないでしょうか?
私たちが開発しているものはアルゴリズムに基づいており、データによって補完されているため、スクリプトベースのプロセス指向のプログラミング スタイルの方が適しています。オブジェクト指向および手続き指向プログラミング
スタイルは白か黒か全く逆ではありません。オブジェクト指向プログラミング言語で開発されたソフトウェアでは、一部の言語であっても手続き型コードが使用されることは珍しくありません。
プロセス指向を使用するかどうかに関係なく、標準開発ライブラリ (JDK、Apache Commons、Google Guava など) にはプロセス指向のスタイル コードも多数あります。
オブジェクト指向スタイルでコードを書くかどうかに関係なく、私たちの最終的な目標は、保守しやすく、読みやすく、再利用しやすく、拡張しやすい高品質のコードを書くことです。避けることができる限り
プロセス指向プログラミングのデメリット 副作用を抑えて制御の範囲内で使えば、オブジェクト指向プログラミングを避ける必要はありません。
手続き型スタイルのコードを指向しています。