PHP オブジェクト指向設計とデータ アクセシビリティ設計について質問する

たとえば、クラス person があります。
データベース操作クラス Conn があります。
person には鶏を買うという操作があり、鶏の情報をデータベースに入れる必要があります
それはどのように設計されるべきですか?
Conn クラスをピリオドに含めて、Conn オブジェクトをインスタンス化し、データベースにアクセスしてデータを挿入する必要がありますか、またはその方法を教えてください。
アドバイスをお願いします！

ディスカッションに返信 (解決策)

class Person extends Conn{
function byji(){
$conn=new Conn;//データベース クラスをインスタンス化する
$conn->add();//Insert Database
}
}

class Person extends Conn{
function byji(){
$conn=new Conn;//データベースクラスをインスタンス化
$conn->add();// データベースに挿入
}
}

私もそう思いますが、同僚はクラス内にデータベース関連のコードを書かない方が良いと言っていました
それが MVC パターンか何かとみなされているかどうかはわかりません。

class Person extends Conn{
function byji(){
$conn=new Conn;//データベースクラスをインスタンス化
$conn->add();// データベースに挿入
}
}

この中でこの場合は、Combination モードを使用することをお勧めします。ここでは継承は不適切です。

1階のnowphpからの返信を引用: class Person extends Conn{
function byji(){
$conn=new Conn;//データベースクラスをインスタンス化する
$conn->add();//Insert intoデータベース
}
}

この場合、組み合わせモードを使用することをお勧めします。ここでは継承は不適切です。 En を教えたところで、どうやって書くのでしょうか?

データベース操作クラス conn をデータベース操作クラスにカプセル化し、conn の静的メソッド add を直接呼び出すことができます

1 階の nowphp からの返信を引用: class Person extends Conn{
function byji(){
$ conn = new connen; // インスタンス化されたデータベース クラス
$ conn- & gt; // データベースを挿入します}}}

これは、組み合わせモードを使用することをお勧めします。ここでは継承は不適切です。

+1
LZ はデザインパターンを学ぶべきです
チキンを買う（このイベントは私を少しおかしくさせます） ビジネスロジックの観点から見ると、これは継承関係ではありません、おそらくあなたのプロジェクトは次のようなものです

ビジネスロジックが誰を決定するか(人) 、操作 (購入)、および何を (製品/チキン) の関係
誰 (主体) が (変数) を操作するか?? 訪問者モード、人は抽象クラスであり、購入は必須の操作ではありません人
誰 (主体) が (変更せず) 何を (変数) を操作するか?? プロトタイプ モード、購入は属性に相当する人の必要な操作です
誰 (主体) が (変更せず) 何を (変数) を操作しますか?? 、購入操作は抽象クラスとして使用され、購入する人をインポートし、購入した製品のチキン
...
ショッピング カート、注文、支払いなどの順序関係をメソッドとして使用することもできます。 conn はそれぞれに導入されます)、属性
としての person は、セッションをメインの抽象クラス (結合モード) として使用し、ログイン、購入、情報の変更、およびその他の操作をメソッドとして使用する (順序付けされていない関係)、および person クラスを使用することに似ています。抽象クラスの属性として
他にも組み合わせ方法はありますので、自分で調べてください

しかし、一般的に言えば、conn がデータベースに接続するとき、conn は person に直接従属する必要があるとは言えず、ステップ従属する必要があります。イベント
そのため、connはブリッジモードやプロトタイプモードなどでは、personとproductの2つのクラスで抽象クラスにリストされ、2番目のレベルは抽象クラスに従属します
イベントクラスを構築し、 conn クラスをメソッドにインスタンス化し、次のように組み合わせます
作業を細分化できるほど、より多くの組み合わせメソッドが作成されます。クラス自体の機能は作業をマージすることなので、当然、それはクラスを単位とします。そして、クラスの下に細分化することは無意味です

上記は単なる私の思考の観点であり、デザインパターンはアイデアであり、特定のパターン内にパターンが存在する可能性があり、誰もが異なるアイデアを持っており、モデルは異なり、固定されていません

はは、できるだけ簡単にやってください

他の人の罠にはまらないようにしてください

はは、できるだけ簡単にやってください

他の人の罠にはまらないようにしてください

はは、良いアドバイスです

デザイン パターンは、多数の実際のプロジェクト開発から抽象化されています
デザイン パターンを学ぶ目的は、自分自身の思考の制限から飛び出し、他の人がどのようにやっているかを確認できるようにすることです。以上です

私自身の開発実践で、モード A とモード B を適用することに固執すると、自分自身に迷惑がかかるのではありませんか?

上記のドンドンの名前を付けるには本を読む必要がありましたが、全て忘れていました
デザインパターンを学ぶ意欲のある人は、最終的には自分の組み合わせの真実を理解できると信じています
悲しいかな、人はいつもこんな感じです 小学生の頃から先生に覚えろと言われたことを覚えていない人はいません。当然、自分で動きを「組み合わせ」なければならないことはわかっていますね
海外の小学校教育でもそうなのかな？

指導してくれた xuzuning と snmr_com に感謝します。私自身のデザイン パターンを持つことが最善です。特定のパターンに固執する必要はありません。