私は手続き型のスタイル (PHP 5 より前に作成されたもの) で書かれたかなり大規模な PHP プロジェクトに取り組んでいますが、私がやっていることのいくつかが少し「ハック」であると感じずにはいられません。他の場所を変更すると、アプリケーションが簡単に壊れる可能性があります。私が見たすべての設計パターンとベスト プラクティスは、OOP にのみ適用されるようです。PHP 5 の OOP 機能を使用してコードの一部を書き始めることもできますが、他のすべての開発者が OOP に十分慣れているかどうかはわかりません。
OOP に慣れている人々にとって「ハック」に見えるのは、手続き型プログラミングの性質だけですか? 大規模な手続き型アプリケーションを保守可能に保ち、新しいバグが発生する可能性を低くする方法を扱った「ベスト プラクティス」の本はありますか?
手続き的な方法で OOP 設計原則/パターンを適用できることはわかっていますが、それを行う場合は、PHP の OOP 機能を使用することもできます。手続き型パラダイムを十分に理解していないだけでしょうか？
手続き型プログラミング、特に PHP では、「カプセル化」の具体的な概念がありません。すべてが利用可能であり、それを変更するのはあなたの仕事ではないので、そうする必要はありません。OOP しか知らない人や、手続き型コードは BAAAAAAD だと教えられた人にとっては、ハックっぽくて間違っているように見えるかもしれません。しかし、人々は長い間それを行ってきました、そしてそれはうまくいきます.
さて、実際に悪い手続き型コードのいくつかを見つけた可能性は同じです。悪い OOP コードと同じくらいたくさんあります。
手続き型コードの基本的なプラクティスは、OOP の場合とまったく同じです。可能であればグローバルを避け、関連する関数をグループ化し、それらを短く保つようにしてください。手続き型プログラミングはパターンの動きよりも数十年先行しているため、実際には「パターン」自体はありません。しかし、クリーンな手続き型コードは、OOP 熱狂者が信じさせるほど醜いものである必要はありません。
私の手続き型コードは、実際には非常に OOish に見えます。$page などの複合構造を渡す関数をよく使用します。これにより、必要に応じて set_title($page, $title) を $page->set_title($title) に簡単に移行できます。これは単なる表記の違いであり、メソッドが達成することに実質的な違いはありません。
デザインパターンは広い分野です。手続き型コードに適用するとばかげているように見えるものは確かにあります。率直に言って、一部の OOP 設計パターンは、クラス ベースのコードでもあまり適切ではありません。ただし、継承したコード ベースを書き換える明確なユース ケースがある場合は、試してみてください。あなたの仲間のコプログラマーがオブジェクト構造のインターフェースにアレルギーを持っているとは思えません。
アプリケーションの問題は、古くて複雑な構造に起因しているように聞こえます。PHP3 スタイルで書かれている場合、たとえば $HTTP_GET_VARS をまだ使用している場合は、試してはいけません。ただし、それがグローバル変数と相互依存のコード状態だけである場合は、何らかのオブジェクト構造を取り込むことができます。
PS: グローバル変数: OOP のシングルトンは、過度に精巧なグローバル変数です。ほとんどのアプリケーションは一連の構成設定を必要とします (読み取るだけで、決して書き込まれることはありません)。これらは、グローバル オブジェクトまたは配列に属します。それ以外はすべて危険です。