【问题标题】:Attributes vs array of attributes at PHP OOPPHP OOP 中的属性与属性数组
【发布时间】:2012-06-22 12:47:27
【问题描述】:

我想知道哪种方式更适合使用。 在控制器类中使用私有属性,或仅使用一个私有属性作为属性数组。

代替:

class User{

    private $id;
    private $firstName;
    private $surname;
    private $age;
    private $gender;
    private $city;
    ...
    ...
}


class User{

    private $data;
}

然后能够做这样的事情:

function __construct(){
     //this would contain id, firstName, username, age, gender...
    $data = $model->getData();
}

谢谢

【问题讨论】:

    标签: php model-view-controller oop class


    【解决方案1】:

    使用数组在编写类代码时,您将失去任何自动完成工具。您将失去检测属性语法错误的能力。事实上,你会让你的代码更混乱,更少描述性。

    使用对象通常是一件好事,它可以提供更好的可维护性,对于将与多个开发人员共享的东西,或者在你编写它几个月或几年后与你自己共享的东西。在我看来,您应该保留属性。一个更令人困惑的代码可能会被“优化”,或者更短的阅读,但如果你想要,只需编写汇编代码。如果您想制作目标代码,请以干净的方式进行,您总会找到可以挽救您未来生活的情况。

    您的问题是,您可能认为在对象属性和模型层列之间保持干净的映射非常痛苦。但无论您尝试什么,这是您在所有应用程序中始终必须编写的最少代码,如果未在此处完成,您在使用对象时仍需了解这些属性。很有可能这是Pattern of Failure

    我们大多数开发人员都信奉“不要重复自己/重复是邪恶的”原则,并且我们会尽可能将其应用于我们创建的软件。但是我们可以犯的最致命的陷阱之一就是挥舞抽象的魔杖太快太宽泛了,我们经常忘记不必要的重复的后果远小于不必要的整合的后果。

    通过您的 DataModel 加载示例,我可以看到例如两个潜在的未来问题:

    • 让我们想象一下,将来您将拥有一个二进制属性,并且该属性需要延迟加载,无论您做什么,您肯定会以围绕 __construct 的肮脏解决方案结束。
    • 您现在正在构建您的类对象的一些实例,您需要为这些对象的数据提供一些不是来自模型的数据(可能是一种缓存),并且您有数千个这些对象。但每次构建此类对象时,所有属性都会从模型中填充。

    事实上,如果你想做一些基于对象相关模型来填充对象属性的东西,你真的应该认为它是一个更通用的东西,可能暗示其他对象、接口、工厂、几种方法。至少不在构造中。

    对数组使用数组,对属性使用属性,让PHP引擎优化属性管理,我相信代码优化器使用属性会比使用字符串索引的数组做出更好的事情。

    【讨论】:

    • 感谢 Regilero 的解释 :)
    【解决方案2】:

    取决于您真正需要对它们做什么,但通常数组会更容易操作。

    P.S.:它们被称为属性,而不是属性。

    【讨论】:

    • 以什么方式?你能给我举个例子吗?
    【解决方案3】:

    如果您有很多属性,请使用数组。这样您就可以使用魔法方法的强大功能,例如:

    public function __set($name, $value)
        {
            echo "Setting '$name' to '$value'\n";
            $this->data[$name] = $value;
        }
    

    参考:http://www.php.net/manual/en/language.oop5.overloading.php#object.set

    【讨论】:

    • 无论如何我目前都在使用它们 :) 那么,使用数组有什么意义,与属性相比有什么优势?
    • 使用数组会丢失自动补全,并且可能会在属性名称上出错
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2013-02-05
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多