ios - 对象未使用的属性有任何危害吗？

Question

我正在重构两个类，试图将它们合并为一个类，之前一个类是另一个类的更重版本。问题是较重的负载等级并没有完全包围较轻的负载等级。我正在考虑只创建一个包含两者所有必要属性的类，其中每个预先存在的类现在都是同一个类的一部分，但使用不同的初始化程序实例化。

为了给你一个想法，假设我想减少这些:

ClassA.h

@interface
@property int shared1;
@property int shared2;
@property int a1;
@property int a2;
@end

ClassB.h

@interface
@property int shared1;
@property int shared2;
@property int b1;
@property int b2;
@end

我的计划是将这些结合起来:

ClassC.h
@interface
@property int shared1;
@property int shared2;
@property int a1;
@property int a2;
@property int b1;
@property int b2;

- (id) initHeavyVersion;  // this will set b1 and b2 as well as shared but not a1/a2
- (id) initLightVersion; // this will set a1 and a2 as well as shared but not b1/b2
@end

当非重叠属性本身可能是相当大的对象时，这样做有什么坏处吗？在我看来，当这些属性未被使用时，它们应该只是携带一些额外的 nil ，仅此而已。所以性能/内存问题应该是最小的。缺点是困惑的公共(public)界面。

我拒绝组合，因为这仍然会产生两个类，而我的目标是将这些类压缩为一个(几乎不惜一切代价)。同样，委托(delegate)会产生同样的问题。

我看到的唯一替代方法是使用关联对象，但这似乎不必要地棘手/花哨，并且仍然依赖于单独的初始化函数。

我们非常欢迎任何批评或替代建议。

Answer 1

面向对象编程的常用方法是使共享部分成为抽象父类(super class)。这样，第一个(具体的)子类只有 A 属性，第二个(具体的)子类只有 B 属性，但是共享 Material 的功能被很好地封装了。执行父类(super class)本身永远不应实例化的规则很容易。

如果您坚持只使用一个类，您基本上是在做面向对象编程的相反。那没有错；只是有点奇怪。如果您打算这样做，我建议您添加一些错误检查。例如，你可以有一个标志来说明这是 A 类型还是 B 类型，这样你就可以在有人试图从 B 类型访问 A 属性时抛出异常。但这对我来说似乎很疯狂，因为您正在以更基本的形式重新实现面向对象。类层次结构的全部目的是用类型学代替条件；你正试图取消这种好处，我不明白为什么。