Question

所以我正在建立一个PHP网站来浏览我的局域网上的电影收藏。它经历了几次迭代，现在我认为面向对象是可行的方法。在当前状态下，我有几个函数可以从数据库中获取电影信息。因此，每当我需要电影的信息时，我必须调用一些函数来获取所有信息并将其传递给其他函数以执行我想要的操作。

我对面向对象版本的想法是在构造函数中执行所有这些'getinfo'函数。所以我只是创建一个电影对象，所有信息都可以使用$movieobj->title等等。

我试了一下，然后想出来测试一下：

class movie{
public $tite = Null;

function __construct($id, $conn){

//set title property
$sql_select = $conn->prepare("SELECT title FROM movie.title 
                              WHERE `movieID` = {$id} LIMIT 1");
$sql_select->execute();
$sql_select->bind_result($val);
$sql_select->fetch();
$this->title = $val;
}

}

这是我想要的，能够使用以下方式获得电影片名：

$movie = new movie(100,$db);

echo $movie->title;

但在实践中，我会在构造函数中有一些类似的代码块来获取电影的其他信息。

这是使用构造函数的错误方法吗？它应该更简单，然后有其他方法从数据库中提取这些信息吗？拥有一个复杂的构造函数会使其他代码变得更简单，但这是不好的做法，还是会导致我看不到的问题？

Answer 1

通常，我个人只会使用构造函数来设置作为参数传递的基本属性值，例如连接，保持构造函数本身尽可能简单;并使用其他方法中的所有实际代码，例如fetch方法（例如getMovie()）来实际执行数据库检索，而不是直接访问movie属性（使该属性成为私有或受保护）。

Answer 2

事实证明，当你在构造函数中使用Google进行数据库查询时＃34;你会发现这个问题 - 即使你强调复杂性 - 已经被反复询问过。

我的看法是在构造函数中查询数据库是不好的做法。

当你在低水平＆＃34;上观看它时没有直接成本，人们的不适感更为普遍。现在，很容易忽视这些非特定的异议，在实践中，当你这样做时，你可能会做得很好，并且与将数据库查询分成fetch方法相比也同样好。实际上，您必须编写更多代码，另外一行来获取数据。

在这种情况下你获得的是另一个层面，而不是你面前的具体小项目：你强迫自己使用平均会使你受益更多的某种风格，即使在短期内你有一个（微小的）劣势。

好处是，当您习惯于分离数据库查询时，您将获得灵活性并且＆＃34;命令＆＃34;：如果稍后更改代码，因为您希望在对象的生命周期内重新加载数据，则必须重构你已经编写的内容（包括在你实例化这样一个对象的所有地方，如果其他人使用你的代码作为模块，他们也必须这样做），或者破坏/重新创建对象。如果fetch函数从一开始就是额外的，它无论如何都会起作用！

所以你的第一个建议对于每年一次周末写个人爱好项目的人来说没问题，如果你是或想要成为一名专业的程序员，原因超出任何一个特定的项目你应该去做更多的事情可维护的＆＃34;有序的＆＃34;长期。长期意味着快速编程和“肮脏”的项目。在一个企业环境中，因为他们应该在5年后最终成为小怪物，因为在前两年，程序员认为这样的捷径是可以的，因为＆＃34;它＆＃34;只是一个小项目＆＃34;。

正如我所看到的，这是这些惯例的真正目的，要照顾你所能看到的（未来）。

Answer 3

您可以将数据库访问与构造函数隔离开来。在这种情况下，您的构造函数应该用于设置类的属性Movie。我的电影课将有一个像Movie($title, $director, $year, ... )这样的签名。 Movie对象将代表我的数据库中的单个行。如果我要重复进行数据库调用，我会考虑将它放在Movie类的静态函数中，或者作为外部函数，我只调用一次。

使构造函数复杂化是不好的做法

3 个答案: