我不是PHP开发人员,所以我想知道在PHP中使用显式getter/setter的优点和缺点是什么,在纯OOP风格中,带有私有字段(我喜欢的方式):

class MyClass {
    private $firstField;
    private $secondField;

    public function getFirstField() {
        return $this->firstField;
    }
    public function setFirstField($x) {
        $this->firstField = $x;
    }
    public function getSecondField() {
        return $this->secondField;
    }
    public function setSecondField($x) {
        $this->secondField = $x;
    }
}

或者只是公共字段:

class MyClass {
    public $firstField;
    public $secondField;
}

当前回答

除了这里已经很好的和受人尊敬的答案之外,我还想扩展一下没有setter /getter的PHP。

PHP没有getter和setter语法。正如Dave所指出的那样,它提供了子类或魔法方法来允许“挂钩”和覆盖属性查找过程。

魔术让我们这些懒惰的程序员在积极参与一个项目并熟悉它的时候,用更少的代码做更多的事情,但通常是以可读性为代价的。

在PHP中,由于强制使用类似getter/setter的代码架构而导致的每个不必要的函数,都会在调用时涉及自己的内存堆栈框架,并浪费CPU周期。

可读性:代码库会导致代码行膨胀,这会影响代码导航,因为更多的LOC意味着更多的滚动。

偏好:个人而言,作为我的经验法则,我接受静态代码分析的失败 作为避免走上这条神奇之路的标志,只要我当时没有明显的长期利益。

谬论:

一个常见的论点是可读性。例如,$someobject->width比$someobject->width()更容易读取。然而,与行星的周长或宽度可以假定为静态的不同,对象的实例(例如$someobject)需要一个width函数,可能需要测量对象的实例宽度。 因此,可读性的提高主要是因为确定的命名方案,而不是通过隐藏输出给定属性值的函数。

__get / __set使用:

属性值的预验证和预清理 字符串。 " 一些{mathsobj1->generatelatex}多 行文本{mathsobj1->latexoutput} {mathsobj1->generatelatex}有很多变量 一些原因 " 在这种情况下,generatelatex将遵循actionname + methodname的命名方案 特殊的,明显的案例 dnastringobj - >同源框(one_rememberable_parameter美元)- >千钧一发——> findrelated () dnastringobj - >同源框(one_rememberable_parameter美元)- > gttccaatttga - > findrelated ()

注意:PHP选择不实现getter/setter语法。我并不是说getter /setter一般都不好。

其他回答

除了这里已经很好的和受人尊敬的答案之外,我还想扩展一下没有setter /getter的PHP。

PHP没有getter和setter语法。正如Dave所指出的那样,它提供了子类或魔法方法来允许“挂钩”和覆盖属性查找过程。

魔术让我们这些懒惰的程序员在积极参与一个项目并熟悉它的时候,用更少的代码做更多的事情,但通常是以可读性为代价的。

在PHP中,由于强制使用类似getter/setter的代码架构而导致的每个不必要的函数,都会在调用时涉及自己的内存堆栈框架,并浪费CPU周期。

可读性:代码库会导致代码行膨胀,这会影响代码导航,因为更多的LOC意味着更多的滚动。

偏好:个人而言,作为我的经验法则,我接受静态代码分析的失败 作为避免走上这条神奇之路的标志,只要我当时没有明显的长期利益。

谬论:

一个常见的论点是可读性。例如,$someobject->width比$someobject->width()更容易读取。然而,与行星的周长或宽度可以假定为静态的不同,对象的实例(例如$someobject)需要一个width函数,可能需要测量对象的实例宽度。 因此,可读性的提高主要是因为确定的命名方案,而不是通过隐藏输出给定属性值的函数。

__get / __set使用:

属性值的预验证和预清理 字符串。 " 一些{mathsobj1->generatelatex}多 行文本{mathsobj1->latexoutput} {mathsobj1->generatelatex}有很多变量 一些原因 " 在这种情况下,generatelatex将遵循actionname + methodname的命名方案 特殊的,明显的案例 dnastringobj - >同源框(one_rememberable_parameter美元)- >千钧一发——> findrelated () dnastringobj - >同源框(one_rememberable_parameter美元)- > gttccaatttga - > findrelated ()

注意:PHP选择不实现getter/setter语法。我并不是说getter /setter一般都不好。

为什么使用getter和setter ?

可伸缩性:重构getter比在项目代码中搜索所有的var赋值更容易。 调试:可以在setter和getter中设置断点。 更简洁:神奇的函数不是很好的解决方案,你的IDE不会建议代码。最好使用模板来快速编写getter。

谷歌已经发布了一个关于PHP优化的指南,结论是:

没有getter和setter优化PHP

不,你不能使用魔法方法。对于PHP来说,魔法方法是邪恶的。为什么?

它们很难调试。 会对性能产生负面影响。 它们需要编写更多的代码。

PHP不是Java、c++或c#。PHP是不同的,它遵循不同的规则。

Well, PHP does have magic methods __get, __set, __isset & __unset, which is always a start. Alas proper (get it?) OO properties is more than magic methods. The main problem with PHP's implementation is that magic methods are called for all inaccessible properties. Which means you have to Repeat Yourself (eg. by calling property_exists()) in the magic methods when determining if name is actually a property of your object. And you can't really solve this general problem with a base class unless all your classes inherit from ie. ClassWithProperties, since PHP lacks multiple inheritance.

相比之下,Python的新样式类提供了property(),它允许显式地定义所有属性。c#有特殊的语法。

http://en.wikipedia.org/wiki/Property_(编程)

There are many ways to create sourcecode in a netbeans-convention. This is nice. It makes thinks such easyer === FALSE. Just use the traditionel, specially if you are not sure which one of the properties should be encapsuled and which one not. I know, it is a boi.... pla... code, but for debugging-works and many other thinks it is the better, clear way. Dont spend to much time with thousend of arts how to make simple getters and setters. You cannot implement too some design patterns like the demeter-rule and so on, if you use magics. In specific situation you can use magic_calls or for small, fast and clear solutions. Sure you could make solutions for design-patters in this way too, but why to make you live more difficult.