オブジェクト指向プログラミングを実際に使用するのはいつですか？[閉まっている]

私は基本的に文字列を操作するプログラムをPythonで書いていますが、OOPの原則を使用してそれを行うべきかどうか疑問に思っていました。クライアントは、彼はコードを気にかけず、ただやりたいと言っていました。

私はオブジェクト指向のコードは定義によるクリーナーではなく、逆にオブジェクト指向でないコードは定義によるくだらないものではないことを知っています。私が尋ねている質問は、多少意見に基づいているかもしれませんが、私が知らないいくつかのルールがあるかもしれません。

何をすべきかについてのさらなる情報：

• .csvファイルを解析し、構成ファイルに基づいてデータを処理します（列は異なる場合があります-列の数や保持するデータなど）
• 上記の処理されたデータを使用して、新しいカスタム形式のデータ（または上記の値のいくつかに基づいた複数のファイル）を作成します
• 最後にフォーマットされたデータを使用して、XMLファイルを作成します。
• XMLコンテンツに基づいてXMLファイルを複数に分割します
• アプリケーションはCLIベースでなければなりません
• もちろん、イベントの記録、CLI引数の解析などのような他のこともあります。

さて、これはまったく大きな/ハードなアプリケーションではなく、ほぼ終了していますが、開発プロセス全体を通して、OOPを使用して行うべきかどうかを自問し続けました。

したがって、私の質問は次のとおりです。アプリケーションでOOPを使用するタイミングをどのように知り、決定しますか。

Pythonはマルチパラダイム言語です。つまり、タスクに最適なパラダイムを選択できます。Javaなどの一部の言語は単一パラダイムOOです。つまり、他のパラダイムを使用しようとすると頭痛がします。「常にOOを使用する」と言っているポスターは、おそらくそのような言語の背景から来ています。しかし、幸いなことに選択肢があります！

プログラムは、入力（csvおよびconfigファイル）を読み取り、出力（xmlファイル）を生成するCLIアプリですが、インタラクティブではないため、ステートフルGUIまたはAPIがありません。このようなプログラムは、入力から出力への関数として自然に表現され、サブタスクの他の関数に委任されます。

一方、OOは可変状態のカプセル化に関するものであるため、対話型アプリケーション、GUI、およびAPIが可変状態を公開するのにより適しています。OOが最初のGUIと並行して開発されたのは偶然ではありません。

オブジェクト指向には、ポリモーフィズムにより、より疎結合のアーキテクチャが可能になり、同じインターフェイスの異なる実装を簡単に置き換えることができるという別の利点があります。依存関係の注入と組み合わせることで、依存関係やその他のクールなものを構成ベースで読み込むことができます。ただし、これは非常に大規模なアプリケーションに最も適しています。記述したサイズのプログラムの場合、オーバーヘッドはあまり大きくなく、明らかな利点はありません。

実際にファイルを読み書きする関数とは別に、ロジックの大部分は、入力を受け取り他の出力を返す副作用のない関数として記述することができます。これは非常に簡単にテストでき、依存関係などをモックする必要があるOOユニットをテストするよりもはるかに簡単です。

ボトムライン：私は、組織のために多くの機能をモジュールに分割することをお勧めしますが、オブジェクトはありません。

GUIのボタンを検討してください。状態（サイズ、色、位置、ラベルなど）があります。それが起こる可能性があります（クリックされた、再描画が必要など）。そのような状況では、オブジェクトとしてモデル化するのが理にかなっています。オブジェクトとして、オブジェクトの状態、実行可能な一連のアクション（メソッド）を含めることができ、イベントを発生させることでアプリケーションの他の部分にオブジェクトが発生したことを通知できます。

OOPは、GUI、およびシステムの一部に揮発性の状態があるその他の状況を処理するための優れたツールです。

説明したような、ソースからデータが読み取られ、処理されて宛先に書き出される他の状況は、異なるアプローチ（宣言（または関数）プログラミング）によって適切に処理されます。データ処理の宣言コードは、OOPソリューションよりも読みやすく、短くなる傾向があります。

ハンマーとのこぎりが両方とも正しく使用されると強力なツールであるように、オブジェクト指向および宣言型プログラミング技術も同様です。おそらく、のこぎりのハンドルを使って釘を木片に打ち込むことができます。同様に、ハンマーで木片を半分に折ることができます。同様に、関数だけでGUIを作成し、オブジェクトでデータを処理できます。ただし、ツールを正しく使用すると、結果はよりクリーンでシンプルになります。

私が使用する一般的な経験則は、多くの状態がある場合、またはユーザーとの対話が必要な場合、オブジェクトを使用することです。それ以外の場合は、（可能な場合は純粋で高次の）関数を使用します。

オブジェクト指向プログラミングは、4つの新しいツールを武器に追加します。

1. カプセル化
2. 抽象化
3. 継承
4. 多型

これらのツールの恩恵を受けるのに十分なほど大きく、複雑になったアプリケーションでOOPを使用します。

この質問は少し混乱しているようです。Pythonで記述している場合、オブジェクトを使用することはかなり確実です。ファイルを開くと、オブジェクトが返されます。結果を生成すると、イテレータオブジェクトを返します。作成する各関数はオブジェクトです。Pythonアプリケーションでオブジェクト指向の価値を疑問視することは、控えめに言っても奇妙に思えます。

ここでのコメントに基づいて、はい、Pythonは機能的なパラダイムをサポートしていますが、それは主にオブジェクトベースです。言語自体と組み込みライブラリは、オブジェクトを中心にしています。はい、ラムダをサポートしています（Javaや、通常OOと呼ばれる他の言語も同様です）が、実際の関数型言語に比べて意図的に単純化されています。

おそらく、オブジェクト指向設計と機能設計に関するこれらの区別は時代遅れになりつつあります。OOで設計されたObject *でポリモーフィック関数を作成し、機能的にスタイルが設定されたfunction *のパラメーターとしてオブジェクト上のその関数へのポインターを渡すと、そのOOですか、それとも機能しますか？それは両方であり、問​​題を解決するための本当に効果的なアプローチだと思います。

本当の問題は、「関数を使ってモジュールを作成するのではなく、独自のクラスの設計を始めるべき時はいつですか？」それに対する正しい答えは、それがソリューションの簡素化に役立つときだと思います。オブジェクト指向言語についても同じ基本的な答えをしたいと思います。

*冗長性は意図的なものです。ここでは、オブジェクトがオブジェクト指向である、または機能が機能していると仮定して非難したくありません。

オブジェクト指向プログラミングの最大の利点の1つは、プログラムフローについて推論する代わりに、状態について推論することです。

多くの場合、オブジェクトが表示され、メソッドが表示されますが、コードの背後にある駆動思考は状態ではなくフローです。

そして、状態について推論すると、コードが複雑になりすぎるとすぐに状態について推論できなくなり、リファクタリングする必要があることがわかるため、適切なOOPコードを簡単に構築できます。

あなたの例を考えてみましょう：csvファイルを解析したい。どこから来たのか：ディスク上のファイル。それをロードしてメモリに入れて解析します。今、あなたのクライアントが来ます：ちょっと私もウェブからファイルを解析したいです。ファイルをロードするための素敵なインターフェースを作成し、Webからファイルを取得するコードを作成するだけで、プログラムの残りの部分はまったく同じであるため、満足しています。

そして良いことは、それをテストできることです。

素人の言葉で：

• 任意の種類のプロジェクトでOOPまたは非OOPを使用できます。
• OOPは万能薬ではありませんが、複雑さの管理に役立ちます。
• それはモジュール性を超えて、区画化についてです。船体が損傷した場合に浮力を保持するために船が持っているさまざまなコンパートメントを考えてください。
• OOPは依存関係を管理する方法であるため、プログラムのさまざまなコンポーネントが他のコンポーネントと通信できる方法が定義されているため、バグの追跡が容易になります。
• プログラムでは、変数、定数、メソッド、ファイル、パラメーター、関数、モジュールなど、多くのことが機能します。これらは、時には予測不可能な方法で相互にやり取りできます。OOPは、物事が互いにやり取りできる方法の数を減らす一連の原則です。OOPを使用して強制することはありませんが、役立ちます。

ただし、考慮すべき他の要因があります。

• あなたのプログラマーはOOP / OODに精通していますか？
• あなたのプログラマーはOOP言語に精通していますか？
• ソフトウェアは時間とともに複雑になると思いますか？
• 将来、コードを拡張または再利用する予定はありますか？
• あなたの「デザイン」は資産になると思いますか？すなわち、成長のために、または将来のプロジェクトの基盤として活用できますか？

誤解しないでください：OOPを使用せずにすべてを達成できますが、OOPを使用すると簡単になります。

しかし...

チームがOOP / OODに習熟しておらず、その分野の専門知識がない場合は、所有しているリソースを使用してください。

したがって、私の質問は次のとおりです。アプリケーションでOOPを使用するタイミングをどのように知り、決定しますか。

常に使用してください。使い慣れたら、すべてに使用します。これは、機能とその使用を適切に抽象化するための優れた方法であり、これはメンテナンスにとって大きな利点です。たとえば、

• 小さなデータ構造オブジェクトは、たとえば多形であることが多いためです。たとえば、何かを解析した後の中間データ構造には、共通の動作を持ちながら特殊な複数の小さなエンティティが含まれることがあります。これらは、特殊な実装と動作、つまりクラス階層（ポリモーフィズム）を備えた、共通の基本クラスまたはインターフェースの優れたユースケースです。

• ロギング、例として、異なるロガーを簡単に置き換えることができるため

• プログラム構造の大きな部分。これは、複数の並列構造を思い起こさせ、マルチCPUプロセッサを活用するためです。たとえば、Webサーバーは、オブジェクトのために、複数の同時要求ハンドラーを簡単に使用できます。

先ほど述べたように、リファクタリングと再利用が容易になるため、優れた抽象化が促進され、すべてメンテナンスが容易になります。OOPは常に受け入れて使用する必要があります。優れたOOPプログラミングは、静的メソッドや静的データを回避し、すべてにオブジェクトを使用します。

オブジェクト指向プログラミングは、フレームワークを作成するツールを提供します。これらのツールは、カプセル化、抽象化、継承、および多態性です。これらのアイデアは、プログラムを2つのセクションに分割するのに役立ちます。

方法-これはコードのフレームワーク部分であり、何らかの抽象化を作成し、ブロックの一般的な動作と他のブロックとの相互作用を決定します。

説明-この部分は、ブロックが実際の作業を行う場所です。ここでは、クラスは「How toセクション」で作成した基本クラスから派生しています。

OOPSから大きな恩恵を受けることができます

1. 既存のフレームワークを再利用でき、「対処方法」セクションで特定の詳細を実装するだけでよい場合。
2. 現在のプロジェクトに実装されている機能は汎用/一般的に使用されている機能であり、他のプロジェクト/将来のプロジェクトは、現在のプロジェクトの開発中に作成されるフレームワークから利益を引き出すことができます。
3. 大きな問題を解決するために、巨大なプロジェクトを一般的なパターンに分解します。
4. 小さなプロジェクトでもOOPSを使用して、それを使用する習慣を身に付け、1〜3種類の問題が発生したときに準備を整えます。