OOPのほとんどの議論では、利点は再利用性であると言われています。クラスを定義するために追加の作業を行うと、後でそれらのオブジェクトの多くのインスタンスと拡張機能を作成できるようになる時間を節約できます。
これの裏付けとして、すべてをオブジェクトに書き込むというトレードオフが節約できる時間と同等になるまで、手続き型プログラミングからOOPプログラミングに切り替えるべきではないようです。
一般に、手続き型プログラミングからOOPプログラミングに切り替えるのに適した時期はいつですか。プロジェクトがその切り替えを行う必要があることを知るために、一般的に探している兆候/特徴はありますか？
この質問は、初心者であるという観点/パラダイムからのものだと思います。プログラマーがオブジェクト指向コードの作成経験を積んだら、このアーキテクチャーを使用して最初からプロジェクトを作成できます。実際、トップダウンのアプローチは、大規模なプロジェクトで膨大な時間を節約できると私は主張します。
しかし、あなたが概説するボトムアップのシナリオについては、あなたはそれを感じなければならないと思います。一般的に言えば、さまざまなアプローチの詳細については、このウィキペディアの記事を参照してください。
PHPに固有の、移行にはこのアプローチを使用できると思います。
このプロセスは、OOの詳細を学ぶための優れた方法であり、最終的にはメリットがわかります。また、私の最初のポイントを教えてくれます。最初から優れた（高次の）デザインの類似性から始めるよりも、何かをOOに変換するのにはるかに長い時間がかかるということです。
非常に単純なアプリケーションではない場合は、今がその時です。実際、将来プログラムを拡張したい場合は難しくなるため、常にOOlyをプログラムする必要があることは議論の余地があります。
文脈にもよると思います。既存のOOPフレームワークを使用するグラフィックスアプリケーションの場合、トレードオフは瞬時に発生します。コンテキストによっては、手続き型GUIコードを作成する必要があります。
ただし、生データ処理を行っていて、OOPフレームワークと相互運用していない場合は、OOPが意味をなさないことに気付くかもしれません。
プロジェクト内で OOP に切り替えるには、非常に時間がかかる場合があります。大量のコーディング、大量のテスト、そして大量のリファクタリングが必要になるため、収益性があるとは思えません。OOP の概念全体が PP とは異なります。
そのため、プロジェクト内で切り替えるのではなく、できるだけ早く新しいプロジェクトに OOP を使用することをお勧めします。慣れてきたら、既存のプロジェクトの OOP 設計について考え始め、徐々に OOP に機能を実装していきます。ただし、これは大変な作業であり、おそらくプロジェクト全体を書き直すように感じるでしょう。
タスクにもよりますが、両方を行った後、次のように考えます。
仕事にはモジュール性が必要だと思いますか? 中央の場所から類似または非類似のものを管理する能力? 多くの繰り返し要素がありますか？迅速な開発または管理の変更は重要ですか?
あなたが攻撃している問題は予測可能で反復的だと思いますか? 解決するための手順に従うことによって、またはアルゴリズムを適用することによって、タスクが最もよく果たされますか?
1 に近い場合は OOP を使用し、2 に近い場合はプロシージャ アプローチを使用します。
迷ったときは使いやすいものを使ってください。
切り替える必要がある兆候を他の場所で探します。あらゆる誇大宣伝にもかかわらず (そして私は OOP の大支持者です)、コードの再利用は、多くの場合、OOP 言語ではわずかに優れているだけです。
OOP は、過去の関数のように、コードを整理するのに役立つ単純な別のツールです。これは素晴らしい便利なツールです。しかし、主な利点は、コードの記述と保守が容易になることです。
もし私が OOP に移行するのにほぼ完全な書き直しが必要だったとしたら、切り替えによる実質的なメリットが明らかになるまでは保留します。あなたのコードが機能するなら、なぜあなたがそれを書き直すのか私にはわかりません。
進行中のプロジェクトのプログラミング スタイルを変更することは、めったに良いことではありません。
エンティティ間でより明確な責任が必要な場合は、いつでもオブジェクト指向の原則を手続き型コードに適用できます。
たとえば、ANSI-C でのオブジェクト指向コーディングに関するこの非常に興味深い本を確認してください。