PHPインベントリプログラムが提供されました。次に、デザインパターンがプログラムをより良くするのか、それともプログラムをより複雑にするだけなのかを言うことになっています.
プログラムはこのような構成になっています。
プログラムは、html に埋め込まれた php スクリプトに分割されます。(A) 1 つのオプション専用の 1 つの完全な php ページがあるか、(B) オプションのロジックが、同様のアクションの他のオプションを提供する別のスクリプト ページ内にあります。（「リセット」や「ホームに戻る」などの簡易ボタンは除きます。）
(A) たとえば、Web サイトを開くと、オプションを含むナビゲーション メニューが表示されます。オプションをクリックすると、たとえば顧客の下に「表示」リンクがあります。クリックすると、「編集」や「削除」など、より多くのオプションに対応する他のリンクを含む別のページに移動します。通常、この Web サイトでは、各オプションが独自の php スクリプト ページに対応しています。たとえば、「View」は list_customers.php に対応します。「編集」は、edit_customer.php に対応します。
(B) もう 1 つの可能性は、そのオプションのロジックが「一般化された」スクリプト ページにあることです。つまり、複数のオプションのロジックが 1 つのページにまとめられているということです。その一例が「削除」です。顧客、ジョブ オーダー、または見積もりを削除する前に、auth.php という名前の php スクリプト ページに移動して、管理者だけが削除できるようにします。ログインしているのが管理者かどうかを確認し、顧客、ジョブ オーダー、または見積もりを削除するためのロジックも auth.php にあります。もう 1 つの例は、顧客のすべての「検索」オプションです。独自のページ search_customer.php がありますが、実際に検索するためのロジックは実際には list_customers.php にあります。このパターンは、顧客の検索、見積もり、または配信レポートの検索を含むすべての検索に適用されます。検索コードは実際には対応する list_* にあります。
より複雑にならないデザインパターンを見つけるのに苦労しています。私が見つけたもののほとんどは OO パラダイムを対象としていますが、このインベントリは確かにそうではありません。私が見つけた唯一の便利な方法は、ログイン（ユーザー名とパスワード）が（ユーザー名、パスワード、ID番号）のようなものに変更された場合であるため、Factoryパターンは確かに役に立ちません。ただし、ログイン機能を持つ php ページは 2 つしかないため、これは役に立たないと思いました。
また、すべての検索ロジックを 1 つのオブジェクトにできるかどうかも調べました。ただし、検索の各タイプには独自のメソッドが必要であり (差分テーブルを照会しているため)、現在の設定と大きく異なることはありません (各検索は現在、対応するリストの php ページにあります)。
役に立つかもしれないと私が見つけた唯一のものは、正規表現の設計パターンです。プログラムのフォームは検証されません。ここに何かアイデアはありますか？
さらに、クラスのトピックはソフトウェア品質です。私の個人的な意見では、このウェブサイトはそれほど大きなプロジェクトではないため、デザイン パターンによってこのウェブサイトはより複雑になります。しかし、私のクラスメートは、これは OO ではないため、保守性が低いと主張しています。しかし、私は思っていました、PHP は OO ではないものとして作成されましたが、正しいですか? したがって、OO 設計パターンに強制的に準拠させると、混乱するだけです。
どう思いますか？この状況に適用できる設計パターンはありますか?