手続きコードとOOPコード

PHPで13000行以上のプロシージャスタイルのプロジェクトを完了しました（OOPは知っていますが、私はそれに精通しているため）、プロジェクトは完全に実行されています。

しかし、OOPに変換する必要がありますか？[ 世界はOOPで忙しいため ]

私のコードは、OOPの機能（カプセル化、継承は基本的に...）を必要としません！

だから私は何をすべきですか？

そして、OOPに変換するとどのような助けが得られますか？

私のコードはOOPの機能を必要としません

あなたはあなた自身の質問に答えました- この場合に OOP が必要でなく、プロジェクトが機能しているなら、それを変換しないでください。

ただし、次のプロジェクトでOOPを使用することを検討する必要がありますが、それが適切な場合のみです。

適切な場所で使用されている限り、手続き型プログラミングには本質的に問題はありません。

いいえ、OOPが必要ないという理由だけではありません。

プログラムがすでに終了しており、満足のいく動作をしている場合、90％を超える時間は、何らかの理由で終了コードを書き換えるのに時間の無駄です。

OOPはすべて強力ではありませんが、OOPを使用すべきではない場所がたくさんあります。OOPが流行しているため、単に使用しないでください。

私の一般的なパラダイム（そしてなぜ3つの主要なパラダイムのどれもがプログラムの正しい方法でも間違った方法でもない）：

手続き型プログラミングは、高レベルで単純な問題があり（低レベルでは複雑な場合もあります）、それに対応して単純な線形コードを書きたい場合に適しています。問題がどこでも強力なデカップリングを必要としない場合、オブジェクト指向および機能よりも間違いなく簡単に記述および理解できます。例：OOまたは機能を使用して物事を分類した後の数値コード、ほとんどの小さなスクリプト、最も小さなサブ問題。

オブジェクト指向コードは、いくつかの懸念事項の実装が複数ある可能性があるため、懸念事項を強く分離する必要がある場合に適しています。例：ほとんどの大規模ビジネスソフトウェア。たとえば、ビジネスロジックはおそらく独立して変更する必要があるため、プレゼンテーションロジックからビジネスロジックを強く切り離したい場合があります。

機能スタイルのプログラミングは、メカニズムをポリシーから強力に分離する必要がある場合に適しています。ポリシー関数を受け入れるメカニズム関数を持つのは良いパターンです。（私はDプログラミング言語のstd.algorithmモジュールを見てそれについて学びました。）ポリシーとメカニズムのコードの境界にある可変状態を抽象化することで、一般的にAPI の推論が容易になります。可変状態がどちらかでプライベートに使用される場合、これは実装の詳細です。関数型プログラミングのその他の強みは、自明の理由から並行性です。

コードは「OOPを必要としない」。この問題またはその特定の問題が$ PARADIGMを「必要とする」か、そのように最もよく解決されると想像するのは、プログラマーです。異なるモードで考えることができます。

1つのパラダイムしか知らないプログラマーは、自分のパラダイムが最も優れていると考えることがよくあります。ワンサイズがすべてに適合し、これまたはそれが現在ファッショナブルである場合、私たちは皆、Procrustesのベッドで寝なければなりません。

OOPの必要性が明確に示されている場合にのみ、プロジェクトをOOPに変換する必要があります。これが発生する可能性のあるシナリオは次のとおりです。

• プロジェクトのスケールアップ
• チームにさらに開発者を追加する

これらのシナリオでも、プロジェクトをOOPに変換する必要はない場合があります。

両方とも良い場合もあれば、悪い場合もあります。しかし、一方をもう一方のように改造することは決して良い考えではありません。

OOが発明された理由を振り返ると、OOP はまったく必要ないことがわかりますが、場合によっては人生がずっと楽になります。

Cコーディングの時代には、非常に大きなプログラムが非常に複雑になり、作業を続けることが困難になる可能性がありました。そこで、彼らはそれをモジュラーチャンクに分割する方法を発明しました。OOPはこのアプローチを採用し、さらにモジュール化して、プログラムロジックのこれらのチャンクでデータを配置し、コードの残りの部分からさらに分離します。

これにより、タスクの巨大な象を100個のマウスサイズのタスクに変更しても安全に、より大きなプログラムを作成できます。追加のボーナスは、これらの「マウス」の一部を他のプログラムで再利用できることです！

もちろん、現実の世界はそのようなものではなく、オブジェクトの再利用は意図された方法で完全に理解されることはありませんが、それが役に立たないパラダイムであることを意味するものではありません。

役に立たないのは、どちらのスタイルのコーディングにも過度に依存していることです。何千もの小さな取るに足りないクラスでオブジェクト指向を行う人は誰も実際に正しくやっていない-彼らは自分自身（または他の誰か）のためにメンテナンスの悪夢を作っている。3つの関数しかない手続き型アプリケーションを作成している人も、人生を難しくしています。最良の方法は、再利用される可能性の高いかなりの量のスタンドアロンコードとデータを提供できる、中規模の地面の大きなオブジェクト（以前はコンポーネントと呼ばれることもありました）です。アプリの他の部分から分離します。

次回のアドバイス：通常の手続き型コードを書いてみてください。ただし、メインデータ構造の単一のオブジェクトを作成してください。機能間でデータをやり取りするよりも、作業する方が簡単であることがわかります。

私のコードは、OOPの機能（カプセル化、継承は基本的に...）を必要としません！

どうやってわかったの？

このプロジェクトを維持する必要がありますか？予定されている新機能はありますか？あなたと一緒に開発する他の人がいますか？繰り返しましたか？コードを把握するのは難しいですか？

答えが「はい」の場合、OOPスケルトンをセットアップしてこの方法で実行することについて考え始める必要があるかもしれません。