封装是实现高内聚低耦合的必要前提，通过private/protected/public控制模块边界；滥用封装（如职责错位、trait/static滥用）反而破坏内聚与耦合。
封装是实现高内聚低耦合最直接的语法手段
PHP 中的 private、protected 和 public 不是装饰性修饰符，而是控制模块边界的开关。没有它们，类就退化为一组松散函数+变量的集合，内聚性无从谈起，耦合也必然升高。
关键点在于：封装本身不等于高内聚低耦合，但它是必要前提。比如一个类把所有属性设为 public，外部代码可随意读写 $this->data、调用 $this->helperMethod()，那这个类就既无法保证内部逻辑一致性（内聚崩塌），又让调用方深度绑定其实现细节（耦合固化）。
- 高内聚靠封装来“收拢”：把只服务于同一职责的数据和方法圈在
private范围内，外界只能通过少数public方法触达这个职责 - 低耦合靠封装来“隔离”：调用方看不到
private属性和方法，也就无法写出依赖它们的代码；哪怕你重写整个private function calculate()，只要public function getResult()行为不变，调用方完全不受影响
当封装被滥用时，高内聚低耦合反而被破坏
常见错误不是封装不够，而是封装错位。比如把本该属于另一个类的逻辑硬塞进当前类，并用 private 包起来——这看似“高内聚”，实则是职责污染。
典型表现：
立即学习“PHP免费学习笔记（深入）”；
- 一个
User类里出现private function sendEmail()，而邮件发送逻辑本应由EmailService承担 -
public function processOrder()内部直接 new 了PaymentGateway和InventoryManager，且这些对象的创建逻辑被藏在private方法里 - 大量
protected属性暴露给子类，导致子类不得不了解父类的内部状态结构
这类“伪封装”会让类表面封闭，实际却承担多职责、强依赖外部，内聚变假，耦合变隐性且更难解。
接口 + 封装 = 可验证的低耦合
仅靠 private 无法自动达成低耦合，必须配合依赖抽象。PHP 中最轻量的实践就是用接口定义协作契约，再用封装隐藏具体实现。
例如：
interface PaymentProcessor {
public function charge(float $amount): bool;
}
<p>class StripeProcessor implements PaymentProcessor {
private $apiKey; // 封装敏感配置
private $httpClient; // 封装第三方依赖</p><pre class='brush:php;toolbar:false;'>public function __construct(string $key) {
$this->apiKey = $key;
$this->httpClient = new \GuzzleHttp\Client();
}
public function charge(float $amount): bool {
// 所有细节都在 private 范围内处理
return $this->doStripeCall($amount);
}
private function doStripeCall(float $amount): bool { /* ... */ }}
这时，订单服务只需依赖 PaymentProcessor 接口，完全不知道 StripeProcessor 的 private 成员，也不关心它怎么发 HTTP 请求。耦合降到了接口层级，内聚则体现在 StripeProcessor 把所有 Stripe 相关逻辑锁死在自己内部。
容易被忽略的边界：trait 和 static 方法对内聚的影响
PHP 的 trait 和 static 方法常被误当作封装工具，但它们天然削弱内聚、抬高耦合。
-
trait是横向复用机制，一旦在多个类中 use 同一个trait，它的private方法就变成多处共享的“隐式全局逻辑”，违背“一个类专注一件事”的内聚要求 -
static方法无法被 mock，也无法被依赖注入替换，调用方被迫与具体实现绑定；哪怕方法体里全是private工具函数，整个调用链仍是紧耦合 - 真正需要复用的逻辑，应该抽成独立类，用构造注入或 setter 注入，再靠封装保护其内部
高内聚低耦合不是靠加 private 堆出来的，而是靠每次新增一个 private 成员时，都问一句：这个东西是否只服务于当前类的单一职责？它是否让外部更难替换或测试这个类？
