我正在开始一个新项目，并试图更好地理解PHP中的OOP。我真正想要看到的是封装的优点和缺点。我的理想目标是看到没有 class-property 暴露给全局范围，因此应该只有方法公开给其他人，他们将依赖于 >私有或受保护的类属性。
我真正关注的另一件事是拥有一个好的继承;然而，我很难面对如何在同一设计中将两者结合起来 - 可能我对错误的理解或对继承的期望过高。为了更好地对以下结构进行成像：
App是基类。Storage类，它们都扩展 App类。Storage类中访问Model方法，理想情况是使用继承而不是依赖注入。 现在，如果我想让其他Storage方法可用，我可以在App类中创建一个公共属性，并将Storage实例存储在那里，所以其他所有class可以简单地访问所有Storage方法，但我想避免它并实现真正的封装，看看它在现实世界中是如何工作的。
另一方面，我也想加入SRP。如果我在App类中实现了一个单独的方法，例如以某种方式允许您访问Storage类，那么我就违反了SRP，因为这不是App的业务。 class - App无法看到子方法，所以我需要提供一种访问它的方法。
同样在上面的例子中，每当我在另一个类中扩展App时，我都必须回到App类并为该类提供一些表单接口。这意味着触及已经正常工作的代码，我认为除非你想调试代码，否则它根本不是一个好的做法，但不是为了添加功能，甚至是最糟糕的：当你将其他人扩展到那个类时。
所以问题是我可以毫不妥协地实施这样的设计，理想情况下是在经过实战考验的结构中吗？
答案 0 :(得分：1)
OOP中的关键原则是封装，内聚和耦合。封装是一种保护机制。您可以限制从外部actor访问类（或类的实例）的内部。 Cohesion描述了类的方法/属性的相关性。 SRP是凝聚力的表达。耦合是指互动类（或它们的实例）之间有多少交互。你需要一些，但希望它们松散耦合。依赖注入是保持类松散耦合的一种方法。例如，您注入依赖项，而不是在内部创建它们，以便消费类不了解它依赖的类是如何创建的（因此如果创建逻辑发生更改则必须更改）。对于OOP来说，继承并不是绝对必要的，但它允许相关的类共享行为;它由两个类之间的 is-a 关系定义，例如，Car是Vehicle的特化。
你想让所有类继承自单个基类，而不是简单的object类来给它们提供相同和重复等常见行为，这违反了松散耦合原则，当然也是一个不好的例子继承。存储机制不是应用程序。应用程序可能拥有存储机制，因此它将是 has-a 关系或组合而不是继承的示例。