【发布时间】：2011-05-03 16:55:54
【问题描述】：
我一直在最近的代码中看到这种格式，甚至在这里：
class Class {
function this() {}
}
而不是
class Class {
[public/private/protected] function this() {}
}
- 不建议总是 指定函数范围？
- 第一种方法不是旧方法吗？
- 如何在第一种方法中， 定义私有和受保护 功能？
【问题讨论】：
【发布时间】：2011-05-03 16:55:54
【问题描述】：
当你声明一个没有任何关键字的函数时，默认情况下是公共的。
是否建议始终指定 功能范围？
如果要将它们用作私有或受保护，则必须定义函数范围。
第一种方法不是旧方法吗？
如果它们仍然被 PHP 接受，那么旧的和新的是什么。
在第一种方法中，如何 定义私有和受保护 函数？
你不能用第一种方法你必须使用关键字。
【讨论】：
- 是的，可能。
- 很难量化一项技术的新旧程度。过去，当 PHP 中的类相对较新时，它可能不那么不推荐了。
- "Class methods may be defined as public, private, or protected. Methods declared without any explicit visibility keyword are defined as public."
【讨论】：
PSR-2 编码标准明确要求 properties 和 methods 都使用可见性修饰符。
但不需要使用public，因为 PHP 5 和 7 向后兼容版本 4，它只对所有内容公开可见，因此它是默认设置。
但是，省略它会引发问题 - 就像您所做的那样。人类非常擅长检测模式和模式中的错误。你会如何看待一段使用protected 或private 的代码（因为你必须这样做），但随机省略public。这是一个错误吗？是故意的吗？这应该触发什么样的秘密行为？或者这仍然是隐藏一些令人讨厌的兼容性问题的 PHP4 代码？作为开发人员，您不想问这些问题，也不想找到答案。
public 是可选的，但 PSR-2 决定要求它。遵循标准建议。
另请注意，属性有a proposal to deprecate and remove the var modifier，并将其完全替换为public。该提案还列出了对 Packagist 上前 10,000 个包的代码分析，指出该代码库中的所有类中有 94% 专门使用 public，其余 6% 使用 var 的类来自四个更大的包很可能仍在尝试与 PHP4 兼容，“Simpletest”（针对 PHP 4 的单元测试框架）处于领先地位。
我所知道的方法的可见性修饰符没有这样的静态代码分析，但趋势很明显：摆脱旧的 PHP4-isms。
【讨论】：
- 是的。始终建议指定函数/属性可见性。
- 是的。没有可见性修饰符的版本一直存在到 PHP4。 PHP5 引入了可见性修饰符。由于遗留代码的向后兼容性，不带可见性修饰符的版本仍被接受并被视为存在
public可见性修饰符。 - PHP4 对可见性一无所知，因此您不能使用这种无可见性修饰符的语法定义
private或protected成员。
【讨论】：
PHP 是作为一种（懒惰的，duck typed）脚本语言诞生的，人们仍在以这种方式使用它。大多数 PHP 程序员都不知道 OOP 是什么，我很清楚这个问题，因为我是从 PHP 开始的，后来确实花了我很多工作。你看到的大约 90% 的 PHP 代码在面向对象、可读性、封装等方面都是混乱和过时的……至少 50% 是纯粹的废话。 :(
当 OOP 程序员发现“依赖注入”实际上被 PHP 开发人员认为是一种创新的设计模式并且需要解释时，我无法告诉你有多少惊讶。
然而，PHP4 没有私有或受保护的范围操作符。那时，您曾经声明一个方法，在方法名称前加上一个或多个下划线，以表明它不打算从外部类调用。
- 是的，推荐
- 是的，从 OOP 的角度来看
- 希望客户能够理解的命名约定
【讨论】：
-
5 年后......你看到的大约 95% 的 PHP 代码在面向对象、可读性、封装等方面都是混乱和过时的......至少 80% 是纯粹的废话。 :( ..
最重要的 PHP4 兼容性和亲和力。
一些开发人员（比如我）忽略了可访问性修饰符，因为他们对脚本语言几乎没有影响。真正的 OOP 语言（如 Python 或 Javascript）没有 private 或 protected 属性，也不需要它。在 PHP 中它有点不同，但是总是 应用这种语法糖是没有意义的。我个人会强调将其保留用于有用的应用程序。
许多 PHP 编码人员不知道“封装”的最初目的，因为它不适用于超出逻辑可见性的未编译代码。事实上，它在 PHP 中增加了更多的脆弱性，因为它在运行时而不是编译时（如在 C++ 中）会引发错误。
而且我忍不住再说一遍：许多编码人员也将它单独用作cargo cult programming idiom 来模拟类似 Java 的语法（以弥补 PHP 感知/过去缺乏 OOP 结构）。
【讨论】：