我当然排除了任何涉及违反数据类规则的原因。因此,如果你知道你不需要继承它(尽管我的理解是,规则在Kotlin 1.1中消失了)。1.将类作为数据类有什么缺点吗?1.为什么不是所有符合条件的类都提供数据类的功能,只要它们仍然符合条件?这些都应该可以被编译器检测到,而不需要特殊的关键字。当然,这个问题的答案可能是显而易见的,这取决于问题1的答案。1.我是否有理由不将所有符合条件的类标记为数据类?
ev7lccsx1#
data修饰符使Kotlin基于主构造函数为大多数常见(%80)场景生成常见方法,如toString,hashCode,equals。这显示了只有少数类应该是data的3个原因:1.大多数非数据类都混合了在主构造函数和类主体中定义的属性。此外,主构造函数通常具有不是字段的参数(但有助于初始化主体中更复杂的字段)。换句话说,data具有非常严格的要求,常规类很少满足这些要求。1.除了第1点之外,创建一个类data可能会损害它的可扩展性。即使有问题的类的布局符合data类的规则,以后也可能有人想在类的主体中添加另一个属性。在这种情况下,他将不得不手动覆盖hashCode,因为它可能在某处使用。1.将类标记为data会向阅读代码的人发送一个消息,即您打算将此类用作数据职业。标记其他类会产生误导。
data
toString
hashCode
equals
dxxyhpgq2#
因为OO编程的一个基本原则:封装。通过设计,我们故意限制其他代码与外部模块交互的方式。这为我们提供了可维护性(更强大的重构)和可读性。
2条答案
按热度按时间ev7lccsx1#
data
修饰符使Kotlin基于主构造函数为大多数常见(%80)场景生成常见方法,如toString
,hashCode
,equals
。这显示了只有少数类应该是
data
的3个原因:1.大多数非数据类都混合了在主构造函数和类主体中定义的属性。此外,主构造函数通常具有不是字段的参数(但有助于初始化主体中更复杂的字段)。换句话说,
data
具有非常严格的要求,常规类很少满足这些要求。1.除了第1点之外,创建一个类
data
可能会损害它的可扩展性。即使有问题的类的布局符合data
类的规则,以后也可能有人想在类的主体中添加另一个属性。在这种情况下,他将不得不手动覆盖hashCode
,因为它可能在某处使用。1.将类标记为
data
会向阅读代码的人发送一个消息,即您打算将此类用作数据职业。标记其他类会产生误导。dxxyhpgq2#
因为OO编程的一个基本原则:封装。通过设计,我们故意限制其他代码与外部模块交互的方式。这为我们提供了可维护性(更强大的重构)和可读性。