3

3つのテーブルを持つデータベースがあります。person、、、playerおよびcoach。このpersonテーブルには、、、、など、とに共通するものが含まれplayerていcoachます。、およびテーブルには、フィールドを含むテーブルへのリンクがあります。サイトにアクセスするすべての人がエントリを持っています。さらに、一部のユーザーはまたはエントリを持っている場合もあります。データベースは、正規化を維持するためにこのように設定されています。firstNamelastNameemailplayercoachpersonpersonIdpersonplayercoach

私のコードには、、、personおよびplayerクラスcoachがあります。と継承player元。以下は、およびクラスの切り捨てられたバージョンです。coachpersonpersonplayer

class person{  
    private $firstName;
    private $lastName;

    public function __construct($firstName, $lastName){
        $this->firstName = $firstName;
        $this->lastName = $lastName;
    }
}

class player extends person{
    private $position;
    private $jersey;

    public function __construct($firstName, $lastName, $position, $jersey){
        parent::__construct($firstName, $lastName);
        $this->position = $position;
        $this->jersey = $jersey;
    }
}

ヘッドアップとして、私はOOPにまったく慣れていないので、わからないことがあれば我慢してください。

（サイド質問、上記のクラスは何と見なされますか、ビュー？）

これらを設定するために、Modelクラスであると理解しているものを使用します（そうですか？）。

class personModel{
    public function getPerson($personId){
        $sql = "SELECT * FROM `person` WHERE `personId` = '$personId'";
        //skipping some sql stuff in here
        return new person($sql['firstName'], $sql['lastName']);
    }
}

しかし、今私の質問の核心は、どのように実装するplayerModelかです。

class playerModel{
    public function getPlayer($playerId){
        //would I do a join SQL here?
        //or would I call personModel::getPerson()
        //or do both these options couple the two classes too tightly?
    }
}

ある種のfactoryクラスは別のオプションでしょうか？もしそうなら、それはどのように行われますか？

person、、playerおよびオブジェクトを作成できる必要がありcoachます。これらすべてのカテゴリに分類されるユーザーがいるからです。

フィードバックをいただければ幸いです。何か明確にする必要がある場合は、頻繁に確認します。

4

1 に答える 1

1

OOPについて話すとき、用語は最初の重要な部分であるため、私はあなたの副次的な質問から始めます:

  • あなたのクラスpersonはモデルです。モデルの意図は、現実の重要な部分をプログラムに投影して、(プログラマーとして) ビジネス ドメインに関する用語を直感的に操作できるようにすることです。playercoach
  • ビューは標準的な OOP 用語ではなく、DB 内の抽象化である場合があるため、テーブルを直接ではなく、1 つまたは複数のテーブルについてビューを操作します。モデルの GUI の場合もあります。

あなたのクラスpersonModelとplayerModelは、永続化コントローラーや、あなたが言ったようにファクトリーよりもモデルではありません。OOP と、モデルをリレーショナル DB からロード/保存する可能性について学習したい場合は、SQL コードと同様に、独自のコードを簡単に作成できます。クラスDBManagementは、のような操作でトリックを実行できますloadPersons()。その操作は DB にクエリを実行し、すべての人物オブジェクトを構築して返します。同様に、保存は で機能しupdatePerson(person $person)ます。

後で、ある種の ORM (Object Relational Mapper) 永続化フレームワークを使用できます (私自身は PHP の経験がありませんが、ドクトリン ORMは興味深いかもしれません。Java または .Net では、Hibernateがよく使用されます)。

さらに、別の方法でモデルを設計することをお勧めします。player確かに、 letおよびcoachから継承するという正しい考えがあったpersonため、 のような共通の属性を共有できますfirstName。しかし、この場合、そのモデルは、最後の文で述べたように、一部のユーザーがすべてのカテゴリに分類されるほど柔軟ではありません。特別なケースは、実際にはプレーヤーである人物がコーチになる場合です。たとえば、Martin がプレーヤーで、今はコーチになる場合、ある Martin オブジェクトを別のオブジェクトに交換する必要があります。それは、マーティンがコーチになったという理由だけで、以前と同じ人物ではないことを意味します。それは奇妙に聞こえますね。

代わりに、すべてのユーザーが常にperson. coachesのユーザーもいれば、 players のユーザーもいます。しかし、常にperson.

説明用の擬似コード:

class Person {
    string firstName;
    string lastName;
    List<PersonRole> roles;
}

abstract class PersonRole {}

class Coach extends PersonRole {}

class Player extends PersonRole {
    int position;
    string jersey;
}

このようにして、すべてのユーザー (=Person) はすべてのロールに対して何も持つことができません。ユーザーが役割を持っている場合、その役割オブジェクトにそのユーザーの特定の役割属性を保存できます。もちろん、人の役割リストは、その人が実際に持っている役割に応じて、時間の経過とともに変化する可能性があります。

きちんとした副作用として、このモデルはデータベース スキーマとより一致しているため、リレーショナル DB スキーマをモデル インスタンスに変換したり、その逆を行ったりするのに問題はありません。

于 2013-01-11T00:28:04.570 に答える