実際にオブジェクト指向プログラミングを使用するのはいつですか？
私は基本的に文字列を操作するPythonでプログラムを書いていて、OOPの原則を使用してそれを行うべきかどうか疑問に思っていました。クライアントはコードについて気にしないと言っていました、彼は物事が欲しいだけですdone。
オブジェクト指向のコードは当然のことながらクリーンではなく、逆にOO以外のコードは当然のことではありません。私が尋ねている質問は、多かれ少なかれ意見に基づくかもしれませんが、私が知らないいくつかのルールがあるかもしれません。
何をすべきかについてのいくつかの詳細：
.csvファイルを解析し、構成ファイルに基づいてデータを処理します（列は異なる場合があります-列の数やそれらが保持するデータなど）- 上記の処理済みデータを使用して、新しいカスタム形式のデータ（または上記の値のいくつかに基づく複数のファイル）を作成します
- 最後にフォーマットされたデータを使用してXMLファイルを作成します。
- コンテンツに基づいてXMLファイルを複数の
XMLsに分割する - アプリケーションはCLIベースである必要があります
- もちろん、他にもいくつかのイベントがあります。いくつかのイベントのロギング、CLI引数の解析などです。
さて、これは大きくてハードなアプリケーションではなく、ほぼ完成していますが、開発プロセス全体の中で、OOPを使用するかどうかを自問してきました。
つまり、私の質問は次のとおりです：アプリケーションでOOPをいつ使用するかを知っている/決定する
Pythonはマルチパラダイム言語です。つまり、タスクに最も適したパラダイムを選択できます。 Javaは単一パラダイムですOOこれは、他のパラダイムを使おうとすると頭痛がすることを意味します。「常にOOを使用する」と書かれたポスターはおそらくそのような言語のバックグラウンドから来ていますが、幸いあなたには選択肢があります！
あなたのプログラムは、いくつかの入力（csvおよびconfigファイル）を読み取り、いくつかの出力（xmlファイル）を生成するCLIアプリですが、インタラクティブではないため、ステートフルなGUIまたはAPIがありません。そのようなプログラムは、入力から出力への関数として自然に表現され、サブタスクの他の関数に委任します。
一方、OOは可変状態をカプセル化することを目的としているため、対話型アプリケーション、GUI、およびAPIが可変状態を公開するのに適しています。 OOが最初のGUIと並行して開発されたのは偶然ではありません。
OOには、ポリモーフィズムがより疎結合のアーキテクチャーを可能にするという別の利点があり、同じインターフェースの異なる実装を簡単に置き換えることができます。依存関係の注入と組み合わせると、これにより、構成ベースの依存関係やその他の優れた機能のロードが可能になります。ただし、これは非常に大規模なアプリケーションに適しています。あなたが説明するサイズのプログラムの場合、オーバーヘッドははるかに大きく、明らかな利点はありません。
実際にファイルを読み書きする関数とは別に、ロジックの大部分は、いくつかの入力を取り、他の出力を返す副作用のない関数として書くことができます。これは非常に簡単にテストでき、依存関係などをモックする必要があるユニットをテストするよりもはるかに簡単ですOOユニット。
結論：整理のためにモジュールに分割された一連の関数を提案しますが、オブジェクトは提案しません。
GUIのボタンを考えてみましょう。状態（サイズ、色、位置、ラベルなど）があります。事態が発生する可能性があります（クリックされた、再描画が必要など）。このような状況では、オブジェクトとしてモデル化することは理にかなっています。オブジェクトとして、オブジェクトの状態、オブジェクトに対して実行できる一連のアクション（メソッド）を含めることができます。また、イベントを発生させることによって、アプリケーションの他の部分にイベントが発生したことを通知できます。
OOPは、GUIや、システムの一部が揮発性状態にあるその他の状況を処理するための優れたツールです。
説明したような、ソースからデータが読み取られ、処理されて宛先に書き出される他の状況は、宣言型（または関数）プログラミングという別のアプローチで適切に処理されます。データ処理の宣言型コードは、OOPソリューションよりも読みやすく、短くなる傾向があります。
ハンマーとのこぎりが正しく使用された場合、どちらも強力なツールであるのと同じように、オブジェクト指向で宣言型のプログラミング手法もそうです。おそらく、のこぎりのハンドルで木の部分に釘を打ち込むことができます。同様に、ハンマーで木片を半分に割ることができます。同様に、関数だけのGUIを作成し、オブジェクトでデータを処理できます。ただし、ツールを正しく使用すると、結果はよりクリーンでシンプルになります。
私が使用する一般的な経験則では、多くの状態がある場合、またはユーザーとの対話が必要な場合は、オブジェクトを使用します。それ以外の場合は、（可能な場合は純粋でより高次の）関数を使用します。
この質問は私には少し混乱しているようです。あなたがそれをPythonで書いているなら、あなたはきっとuseオブジェクトに行くでしょう。ファイルを開くと、オブジェクトが返されます。結果を生成すると、イテレータオブジェクトが返されます。作成する各関数はオブジェクトです。 OOアプリケーションでPythonの値を質問することは、控えめに言っても奇妙に思えます。
ここのコメントに基づいて、はい、Pythonは機能パラダイムをサポートしますが、それは主にオブジェクトベースです。言語自体と組み込みライブラリはオブジェクトを中心にしています。はい、それはラムダをサポートします（Javaおよび通常OOとして記述される他の言語の数もそうです）が、真の関数型言語と比較して 意図的に 単純です。
おそらく、OO設計と機能設計に関するこれらの区別は時代遅れになっています。 OO設計されたObject *で多態性関数を作成し、オブジェクトのその関数へのポインターをパラメーターとして機能的にスタイルが設定された関数*に渡すと、そのOOまたはそれは機能していますか？それは両方であり、問題を解決するための本当に効果的なアプローチでもあると思います。
本当の問題は、「関数を備えたモジュールを作成するだけでなく、独自のクラスの設計をいつ開始すべきか」だと思います。それに対する正しい答えは、ソリューションを簡素化するのに役立つ場合だと思います。オブジェクト指向言語についても、基本的な答えは同じです。
*冗長性は意図的なものです。ここでは、オブジェクトがOOであると想定したり、機能が機能していると非難したりしません。
オブジェクト指向プログラミングの最大の特徴の1つは、プログラムフローについて推論する代わりに、状態について推論を開始することです。
多くの場合、オブジェクトやメソッドが表示されますが、コードの背後にある運転の考え方は、状態ではなくフローであることがわかります。
そして、状態について推論すると、コードが複雑になりすぎるとすぐに、状態について推論できなくなり、リファクタリングの必要があることがわかるため、優れたOOPコードを構築するのは簡単です。
あなたの例を考えてみましょう：あなたはcsvファイルを解析したいと思います。それはどこから来たのか：ディスク上のファイル。それをロードしてメモリに入れ、解析します。さて、クライアントが来ました。Webからファイルを解析したいのですが。ファイルをロードするための素敵なインターフェースを作成し、それをWebからフェッチするコードを作成するだけでよいので、あなたは満足しています。残りのプログラムはまったく同じままです。
そして素晴らしいのは、それをテストできることです。
簡単に言えば：
- 必要なあらゆる種類のプロジェクトでOOPまたはnon-OOPを使用できます。
- OOPは万能薬ではありませんが、複雑さの管理に役立ちます。
- それはモジュール性を超えて、それは区分化についてです。船体が損傷した場合に浮力を維持するために船が持っているさまざまな区画を考えてください。
- OOPは依存関係を管理する方法であり、プログラムのさまざまなコンポーネントが他のコンポーネントと通信できるように定義された一連の方法しかないため、バグを簡単に追跡できます。
- プログラムでは、変数、定数、メソッド、ファイル、パラメーター、関数、モジュールなど、多くのことが機能します。これらは、時々予測できない方法で互いに相互作用する可能性があります。 OOPは、物事が相互に作用する方法の数を減らす一連の原則です。これを行うためにOOPを使用する必要はありませんが、助けます。
とはいえ、考慮すべき他の要因があります：
- あなたのプログラマーはOOP/OODに精通していますか？
- プログラマーは、OOP言語に習熟していますか？
- ソフトウェアは時間とともに複雑になると思いますか？
- 今後、コードのスケーリングや再利用を計画していますか？
- あなたの「デザイン」は資産になると思いますか？つまり、成長のために、または将来のプロジェクトの基盤としてそれを活用できますか？
誤解しないでください：OOPを使用しなくてもすべてを達成できますが、OOPを使用すると簡単になります。
だが...
チームがOOP/OODに精通しておらず、その分野の専門知識がない場合は、持っているリソースを使用してください。