为何将Guitar属性拆分至GuitarSpec属于OOP封装？

问题背景 #

初始的Guitar类实现如下：

public class Guitar 
{
    private String SerialNumber ;
    private double Price;
    private String Model;
    private Type Type;
    private Builder Builder;
    private Wood BackWood;
    private Wood TopWood;
} 

该类原本通过Search(Guitar)方法实现吉他搜索。之后重构出GuitarSpec类：

internal class GuitarSpec
{
    public Builder Builder { get; set; }
    public string Model { get; set; }
    public Enums.Type Type { get; set; }
    public Wood BackWood { get; set; }
    public Wood TopWood { get; set; }
}

修改后的Guitar类结构变为：

internal class Guitar
{
    public string SerialNumber { get; set; }
    public double Price { get; set; }
    public GuitarSpec GuitarSpec { get; set; }
} 

现在搜索方法改为SearchMethod(GuitarSpec)，作者称这一设计属于封装机制。但常见的封装示例多为「私有字段搭配公共方法/构造参数」，因此疑惑这种代码结构为何属于OOP封装？

解答 #

封装的核心不止是访问控制（私有字段+公共访问器），更在于将相关状态/行为打包、隔离变化、明确职责边界，这次重构正是从这些层面体现了封装：

• 将相关数据封装为独立单元
  原来的Guitar类混杂了两种属性：一类是吉他的核心交易标识（序列号、价格），另一类是吉他的规格参数（品牌、型号、木材类型等）。把规格参数抽成GuitarSpec类，是将语义上相关的一组数据封装成一个独立的逻辑单元，让这部分属性有了清晰的归属，外部可以直接通过GuitarSpec来操作规格信息，而不用零散地处理单个字段。

• 封装变化点，降低耦合
  搜索逻辑只关心吉他的规格参数，原来的Search(Guitar)方法需要依赖整个Guitar对象，导致搜索逻辑和Guitar的其他属性（比如价格）产生不必要的耦合。重构后用SearchMethod(GuitarSpec)，相当于把「搜索所需的参数集合」封装起来，后续如果搜索需要新增规格字段（比如颜色、尺寸），只需要修改GuitarSpec，无需改动Guitar类或搜索方法的参数结构，有效隔离了变化的影响范围。

• 实现职责单一的高内聚设计
  封装的目标之一是让类的职责更单一。重构后的Guitar类专注于管理吉他的交易属性，GuitarSpec专注于管理规格参数，每个类只处理自己职责内的内容。这种划分让类的内部细节（比如规格字段的调整）不会扩散到其他类，符合封装「高内聚、低耦合」的核心原则。

内容的提问来源于stack exchange，提问作者KAAMIRLI