php
オブジェクト指向、データベース
-----解決策---------
1
LZはデザインパターンを学ぶべきです
チキンを買う (この出来事は私を狂わせます
) ビジネス ロジックの観点から見ると、これは継承関係ではないかもしれません。おそらくあなたのプロジェクトは次のようなものです
。
ビジネス ロジックは、誰 (人)、操作 (購入)、何を (製品/鶏肉) の間の関係を決定します
誰 (主体) が (変数) を操作する (変数) - 訪問者モード、人物は抽象クラス、購入は人物の必須操作ではありません
誰 (主体) が (変更せず) 何を (変数) を操作する - プロトタイプ モード、購入は人の必要な操作であり、属性に相当します
誰 (変数) が操作する (主体および変更なし) 何を (変数) - ブリッジ モード、抽象クラスとしての購入操作、輸入者が購入する、および製品チキンを購入する
…
構築モードを使用することもできます。ショッピング カート、注文、支払いなどはメソッド (それぞれ conn を導入します) として、また人物として属性として使用されます
同様に、セッションはメインの抽象クラス (結合モード) として使用され、ログイン、購入、データ変更などの他の操作はメソッドとして使用され (非順序関係)、person クラスは抽象クラスの属性として使用されます。クラス
他にも組み合わせ方法がありますので、自分で勉強してください
しかし、一般的に言えば、データベースに接続するときに conn が person に直接従属するべきであることは明らかではありませんが、event に従属するステップです
したがって、conn はブリッジモードでは person クラスや product クラスとともに抽象クラスに配置され、プロトタイプモードでは第 2 レベルの抽象クラスに従属します
イベントクラスを構築し、conn クラスを次のようなメソッドにインスタンス化する方が良いです
作業を細分化すればするほど、より多くの方法で作業を組み合わせることができます。もちろん、カテゴリ自体の機能は作業を組み合わせることであり、カテゴリの下に細分化することは無意味であるため、カテゴリを単位として話しています。
上で述べたことは単なる私の考え方です。デザインパターンは、あるパターンの中にパターンが存在する可能性があり、人それぞれ異なる考え方を持っているため、パターンは異なります。
--- ---ソリューション ソリューション-------------------
実際の多数のプロジェクト開発から設計パターンを抽象化します
デザイン パターンを学ぶ目的は、自分自身の思考の限界から解放され、他の人がどのようにやっているかを確認することです。以上です
あなた自身の開発実践において、モード A とモード B を適用することに固執する場合、あなた自身に問題を引き起こしていませんか?------解決策------ - -----------
上記のドンドンに名前を付けるために本を読まなければならなかったのですが、すっかり忘れていました
デザインパターンを学ぼうとする人は誰でも、最終的には自分の組み合わせの真実を理解できると私は信じています
悲しいかな、人はいつもこんな感じです。小学生の頃から先生に言われたことを覚えていない人はいませんか?
外国の初等教育ってこんな感じなのでしょうか?