在我理解的情况下,OOP与PHP中的过程式编程的最大优点是函数名称的分离(命名空间的类型)。
所以现在当我们从版本5.3开始拥有命名空间时,您的想法是什么 - 对于大多数情况(中小型网站),当我们需要快速且重新结构化的代码时,使用命名空间+原型编程比定义更有优势并以OOP写作。
优点:
代码示例:
namespace User;
function setPassword ($user_id) {
$pass = _generatePassword();
$sql = 'UPDATE `users` SET `password` = '.escape($pass).' WHERE `user_id` = '.escape($user_id);
$result = mysql_query($sql);
if (mysql_affected_rows() == 1) return $sql;
else return $sql;
}
function _generatePassword () {
$char = '0123456789abcdefghijklmnopqrstuvwxyz';
$str = '';
for ($i = 1; $i <= 6; $i++) {
$str .= $char[mt_rand(0, strlen($char))];
}
return $str;
}
用法:
$user_id = 5;
User\setPassword($user_id);
我在征求意见。我知道这只是开发人员的风格,但也许我错过了一些东西。
PS。对于大多数情况(中小型网站) - 我的意思是当你为大多数一次开发的客户做网站时,从长远来看有一点功能改进。
答案 0 :(得分:3)
你正在以错误的方式思考OOP。如果您试图将OOP与过程命名空间进行比较仅仅是作为组织代码和函数调用的两种不同方式,那么肯定名称空间似乎会更有效。
OOP的优势不在于组织一个充满功能的对象。这只是将OOP类视为充满函数的大“utils”类。 OOP的优势不在于组织。这是一种完全不同的构建程序的方式,它会导致您将代码分解为更小,更谨慎的实体。我在所有PHP程序中都使用OOP,即使对于小项目也是如此。
在进行任何访问数据库的项目时,OOP的优势对我来说最为明显(现在一切都很好)。我创建小类来为每个数据库表建模,然后将这些表中的信息作为对象访问。我在我的所有项目中都使用了一些基类,这些基类定义了如何将表映射到对象,所以我不再重新键入或粘贴mysql命令。我只是使用这些对象,它们继承了从数据库中插入,更新和删除所需的所有功能。
在代码中确实更有用(特别是如果你使用具有代码完成功能的PHP ide),可以在代码中看到这一点:
echo "Hello, {$someDataObject->name}!";
比这个:
echo "Hello, " . $row['name'] . "!";
差异可能不会很明显。这两个示例都是用于打印表列的单行代码。但第二个例子要求我知道我脑子里的列名。第一个示例将列名称作为属性嵌入到类中。我的代码检查器知道所有属性,所以当我编码时,它会显示我输入的所有属性的列表。
维护课程比你想象的要容易。根据您选择的对象框架,有一些脚本可以从表生成类并使它们保持最新。而且我发现它更少的错误和容易使我的对象类保持最新的错误而不是让数据库更改破坏代码,因为列名更改然后我必须在几十个地方更新这些列引用。是的,有搜索和替换,但您是否看到更新一个文件进行列更改的优势,而不是更新每个对$ row ['some_column']的引用?
我希望这有助于回答你的问题。
答案 1 :(得分:1)
我认为这是一个有效的问题。使用OOP样式编程时,随着问题空间的增加和代码库的增加,往往会引入大量开销。可以说,对于小型项目,使用OOP,功能性或程序性之间没有任何实际区别,但此后情况并非如此。
OOP编程原则所吹捧的优势之一,尽管不是唯一的优点,是命名空间为您带来的好处。此外,在很多情况下,强制使用类会引入更高级别的更紧密耦合和一些依赖性。这里提出的是仅使用命名空间编写过程代码,这将允许以更自然的方式重用函数。
在一般情况下很难更具体,原始问题中提出的例子并没有揭示出因上述原因避免使用类的一些潜在好处。
不使用OOP样式的一些参数与支持和反对函数式编程语言的参数更具可比性。这里添加的一个有趣的例子是查看相对较新的go语言,由google的人员编写,它更进一步,允许使用自己命名空间中的包来定义函数与结构或接口分开。
如果谷歌的人看到这里介绍的方法的一些优点,对我来说,考虑这似乎并不是一件坏事,而不仅仅是为了思考。