OOPは主にツールです
私にとって、PLOでの生活は非常に簡単なフレーズから始まりました。 その名詞はすべてオブジェクトです。 すべての動詞はアクションであり、形容詞は特性です。 大学の3年生でこのフレーズを聞いたのは面白いです。 OOPの基本は、学校でのロシア語の授業で行われていることがわかりました。 悲しいかな、私はこれらのレッスンを過小評価する方法を理解しただけです。
私の意見では、OOPの主な利点は、プログラミングと通常のスピーチの両方でOOPを使用するという事実です。 私たちは自分たちの生活を続け、さまざまな概念について議論し、誰が何をすべきかについて議論することができます。 これは毎日数回発生します。 そのような議論をすべてワークスペース、プログラミング領域に転送してみてください。 私たちは顧客と当社の契約について話し合います。それがここにあるのが契約の対象です。 私たちは私たちのサイトで契約を公開する可能性について議論しています-そして、ここに契約を公開できるというふるまいがあります。
モデルを定義する際に文中の言語と単語をこのように単純に使用することで、顧客とコミュニケーションをとるときに言語を歪めないようにできます。 契約がその結論に取り組んだ人々にボーナスを支払うことができるはずだと彼が言ったら、私は契約のクラスで簡単な方法を使用してこれを簡単に行うことができます。 その後、私にとって、この方法は契約に基づいてお金が支払われることを示すシグナルとなり、この機能がどこにあるかを正確に知っています。
特定の類似性を引き出すと、私にとってはクロスプラットフォーム開発環境に似ています。 たとえば、同じ.NET。 C＃、VB、またはその他の言語で書かれた言語は関係ありません。コードが中間言語にコンパイルされることはわかっています。 だから、私がプログラマーとしてC＃を使用し、顧客がVBに関する要件を言うと想像してください。 このような状況では、OOPは私と顧客が同じ波長になるように（フレーズと同じように-同じページ上にあるように）収束するのに役立つまさにそのコンバーターとして機能します。 そして、これは以前は見えなかった重要な機能です。 OOPはツールです。 コードに実装するモデルはツールです。 私がオブジェクトを作成し、それで遊んで、その内部状態を変更し、そこから何らかの排気を取得したと言った場合、必ずしも完全に保存されるわけではありません。 彼女は、私が開いて計算を行い、保存せずに閉じるエクセルプレートのように、作業に役立つドライバーのようなものです。 これは、データを操作するためのツールであり、全体的な永続モデルではありません。 多くの場合、開発チームは、データベースを扱う人と、コード、モデル、およびユーザーインターフェイスを直接扱う人を分離します。 これらのチームを分離することは推奨しませんが、反対に、共同作業を歓迎します。 したがって、データにアタッチされていない場合、モデルのリファクタリングは、このデータセットを操作するためのツールの改善のように見えます。 それは、新しい改良されたドリルをリリースしたり、より厚い壁を掘削するための新しいドリルをリリースするようなものです。
アクションは、コミットした人よりも重要です
OOPプログラマーが最初にクラスを書くという神話があります。 ほとんどの場合、このエラーは、オブジェクト指向言語ではすべての操作と機能が何らかのオブジェクトで実行されるという事実に起因します。つまり、動作を記述するにはクラスを作成する必要があります。 すべてはこのように見えますが、クラスを作成することの意味を理解することは、空のクラスの作成から始まり、その状態と動作の説明で終わる、すべての人にとって異なっています。 ほとんどの場合、作業チェーンは次のようになります。何らかのシステム動作が必要であることを理解し、この動作のコントラクトを宣言することでインターフェイスを記述します。 次に、どの時点で完了する必要があるかを評価し、既存のオブジェクトから理想的なアーティストを選択するか、新しいアーティストを作成します。 クラスを書くことは決してありませんし、それをどうするかを考えます。 つまり、チェーンは常に動作から始まります。 機械的には、多くの場合、新しいクラスを作成し、その中にメソッドを宣言するだけです。 この神話は、PLOの物事の機械的な理解から生まれたことがわかります。 時々、私たちは非常に迅速に考え、必要なシステム動作の種類を認識した後にのみ、それが実行するオブジェクトの種類についての決定を既に行います。 これはまた、私たちがオブジェクトから踊っているという印象を与えますが、思考は常に行動から始まるため、そうではありません。 さらに、顧客はこれで私たちを助けます。 彼は常に何かをするシステムを必要としており、契約や注文などの概念だけではありません。
反対者の考えを計算するタスク
手続き型アプローチとオブジェクト指向型アプローチを比較できないようにするには、単純な質問を自問しました。オブジェクト型アプローチの代わりに手続き型アプローチをどこで使用できますか？ 正直に言うと、OOPが何らかの形で機能的アプローチを明らかに失った領域は知りません。 それにもかかわらず、言語で展開することの1つは、コストがかかり、複雑な計算、アルゴリズムであるということです。 いくつかの複雑なルールに従って値の計算を実行する必要がある場合の例を見てみましょう。 手続き型のスタイルを説く人がどのように行動するかはわかりませんが、反対者の考えは理解できます。 ポイント1、私はこの計算をセマンティックなステップに分解します。たとえば、この係数を計算し、次にこれを計算し、最後に計算します。 計算の各段階は、プロセス全体に参加するオブジェクトです。 ステップ間で通信し、データ交換を可能にするために、すべての中間計算を保存する別の補助オブジェクトを作成します。 次に、これらのオブジェクトを1つのチェーンにまとめ、必要な値を返す1つのメソッドを説明します。 このようなコードはテストに便利で、読みやすく、理解するのは難しくありませんが、1つあります。 オブジェクトは必ずしも現実世界の名詞ではなく、アクションでもあるという理解を少し変える必要があります。 しかし、これはすでに難しくなっており、明らかにOOPを支持していません。 実際のオブジェクトまたは概念がオブジェクトとして使用され、オブジェクトがアクションになる可能性のある線を定義することは非常に困難です。 はい、そのようなオブジェクトのメソッドがどのように見えるかを理解するために、ある程度の努力をする必要があります。 何らかの行動の振る舞いが判明し、これはすでにロシア語を超えています。 物事の私の理解から、私はOOPが本当にこのタスクのための最良の選択ではないが、それは理解において常に単純で透明であるとは限らないからだと結論付けます。