どこにいても、OOPの長所/短所や手続き型アプローチについて議論しないようにしています。
必要に応じて、プログラムを多くの機能と見なしてください。 欲しいですか-多くのオブジェクトのように。 たいですか-一般的に面倒です。 そして、同志シャリトと彼のステートマシンがあります。 それはビジネス上の問題です。
パラダイムが理由で生じたことを理解することは重要です。 OOPの出現は、特に、プログラムの拡大とそのアーキテクチャの複雑さによって引き起こされます。 現在、エンドツーエンドの機能を別のエンティティにもたらし、人の労力を大幅に節約できるAOPについてよく話します。
また、プログラムの目標を明確に定義することは非常に重要です-どのパラダイムが適切かによって異なります。 拡張性に関心がある場合は、おそらく、OOPについて知る必要があります。 速度が手続き的なアプローチである場合。
一つのパラダイムに狂信的な執着を避けることは重要です。
いずれにせよ、定義した後は、リファクタリングを忘れないでください（Martin Fowlerが飛び出して叫びます-コードの匂いを嗅いでください！匂いを検出してください！）。 OOPでのほとんどすべてのリファクタリングですが、関数もリファクタリングできます。
さらに多く：パターンが想起されます。これは、差し迫った言語の問題を回避し、アーキテクチャ上の問題を解決するステレオタイプの方法です。 パターンがある場所
-POEAAを
備えた GOFとFowlerが
あります。 次に、
TDDがポップアップし、コードを書く前にテストを記述します。 さらに-さらに、理解できない略語の山と方法論の森があります。
多くのことが書かれ、書かれており、そのようなトピックについて書かれています。
しかし、特効薬はありません。