VB.NET数据类计算属性三种实现方案对比及OOP合规性、内存占用疑问

认知修正 #

首先纠正你对方案1的错误认知：类的方法、属性Getter的执行逻辑是存储在.NET的类型方法表中，所有类实例共享同一份逻辑代码，哪怕你有10000个Package实例，200行的计算逻辑也只会在内存里存一份，完全不会出现每个实例占200行逻辑内存的情况，你之前的内存顾虑是不成立的。

三种方案的额外优缺点 #

方案1：类内直接实现计算逻辑

• 额外优点：
  • 符合封装原则，Package的体积计算逻辑本身就是类的固有行为，内聚性最高
  • 不存在外部依赖，类可以独立移植、单元测试，不需要额外引入计算类
  • 天然保证数据一致性：只要长宽高修改，下一次访问Cubic属性自动返回最新值，不需要额外同步逻辑
• 额外缺点：
  • 如果计算逻辑需要被其他非Package的类复用（比如其他异形包装类也需要算体积），会出现代码冗余
  • 计算逻辑如果非常复杂，会让Package类的代码变得冗长，不符合单一职责原则的极端要求

方案2：调用独立计算类实现

• 额外优点：
  • 计算逻辑可以被其他类复用，适合多类共用同一种体积计算规则的场景
  • 符合单一职责原则：计算逻辑单独维护，修改计算规则不需要改动Package类的代码
• 额外缺点：
  • 你当前的写法每次访问Cubic属性都会new一个CalculationClass实例，会增加GC压力，尤其是高频访问的场景
  • Package类依赖外部计算类，增加了依赖复杂度，单元测试需要额外mock计算类

方案3：外部计算后赋值

• 额外优点：
  • 对于体积计算非常耗时、且长宽高不会频繁修改的场景，一次计算多次读取，性能最高
• 额外缺点：
  • 除了你提到的数据不一致问题，还会让类的状态不可控：外部可以随意修改Cubic的值，破坏了类的封装性，无法保证Cubic和长宽高的对应关系
  • 增加了外部调用方的心智负担：每次修改长宽高都要手动触发重新计算，容易出bug

补充问题解答 #

A) 第二种方案是否违反OOP方法论？

不违反。只要你的设计符合当前业务场景：如果体积计算逻辑本身就是需要在多个类之间复用、或者计算规则经常需要独立调整，把计算逻辑抽离到独立服务类是完全符合OOP的单一职责、依赖倒置原则的，反而是不合理的把所有逻辑都塞到数据类里才会违反单一职责。
如果计算逻辑只属于Package类独有，没有复用需求，那抽离到外部类反而属于过度设计，没必要。

B) 第二种方案中，每个Package类实例都会创建新的CalculationClass实例吗？还是所有Package实例复用同一份CalculationClass代码？

按你现在的写法：每次访问Cubic属性都会创建一个新的CalculationClass实例，同一个Package实例访问10次Cubic就会创建10个实例，这是完全没必要的浪费。你可以把CalculationClass的Cubic方法改成静态方法（Shared），或者在Package类里持有一个静态的CalculationClass实例，所有Package实例共享同一个计算类实例，就不会重复创建了。
另外不管你创建多少个CalculationClass实例，计算类的代码逻辑始终是所有实例共享的，只会存一份，重复创建的只是实例的对象头、字段等少量数据，不会重复存代码逻辑。

最佳实践推荐 #

根据不同业务场景选择：

1. 如果体积计算逻辑只有Package类使用，没有复用需求：直接选方案1，是最简洁、不容易出问题的实现，完全不需要有内存顾虑。
2. 如果计算逻辑需要被多个类复用、或者计算规则需要经常调整：修改方案2的写法，把计算类的方法改成静态，或者注入单例的计算类实例，既满足复用需求，也不会有重复创建实例的问题。
3. 如果体积计算非常耗时、且Package的长宽高属性在实例创建后几乎不会修改：可以选方案3的变种，在Package类内部做懒加载+过期校验：长宽高修改时标记Cubic为过期，访问Cubic时如果过期才重新计算，否则直接返回缓存值，兼顾性能和数据一致性。

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