3

我有一个包含 3 个表的数据库。person, player, 和coach. 该person表包含player和coach的共同点，例如firstName、lastName和email。,player和coach表然后有一个链接返回到person带有personId字段的表。每个访问该站点的人都有一个person条目。此外，一些用户可能也有player或coach条目。数据库以这种方式设置以保持规范化。

在我的代码中，我有一个person、player和coach类。和player继承coach自person。下面是person和player类的截断版本。

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 很陌生，所以如果有我不知道的事情，请多多包涵。

（附带问题，上面考虑的类是什么，视图？）

现在为了填充这些，我使用我理解的模型类（对吗？）。

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，player并且coach是模型。模型的目的是将现实的重要部分投射到程序中，以便您（作为程序员）可以直观地使用有关业务领域的术语。
  • 视图不是标准的 OOP 术语，有时它是数据库内部的抽象，因此您可以使用视图来处理一个或多个表，而不是直接使用表。有时它是模型的 GUI。

您的类与其说是模型personModel，playerModel不如说是持久性控制器，或者如您所说的工厂。如果您想学习 OOP 以及从关系数据库中加载/保存模型的可能性，您可以轻松编写自己的代码，类似于 SQL 代码。一个类DBManagement可以通过诸如loadPersons(). 该操作查询数据库，构建所有人员对象并返回它们。同样，保存可以与updatePerson(person $person).

稍后您可以使用某种 ORM（对象关系映射器）持久性框架（我自己没有使用 PHP 的经验，但学说 ORM可能很有趣。在 Java 或 .Net 中经常使用Hibernate）。

另外，我建议您以另一种方式设计模型。事实上，你有正确的想法来让player和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）都可以对每个角色都没有。如果用户具有角色，那么在该角色对象中，您可以保存该用户的特定角色属性。当然，一个人的角色列表会随着时间的推移而改变，具体取决于该人实际拥有的角色。

一个简洁的副作用是该模型更符合您的数据库架构，因此您应该可以轻松地将关系数据库架构转换为模型实例，反之亦然。

于 2013-01-11T00:28:04.570 回答