什么时候使用结构而不是类？ [关闭]

#1 楼

遵循的一般规则是，结构应该是相关属性的小型，简单（一级）集合，一旦创建，它们就不可变。

C＃的优点是，结构和类在声明中除了define关键字外没有显着区别；因此，如果您觉得需要将结构“升级”到类中，或者相反，将类“降级”到结构中，则更改关键字通常很简单（还有其他一些陷阱；结构不能派生来自任何其他类或结构类型，它们不能显式定义默认的无参数构造函数。）

我之所以说“大部分”，是因为了解结构最重要的是，值类型，将它们像类（引用类型）一样对待可能会导致痛苦的一半。特别是，使结构的属性可变可以导致意外的行为。

例如，假设您有一个具有两个属性A和B的类SimpleClass。您实例化此类的副本，初始化A和B，然后将实例传递给另一个方法。该方法进一步修改了A和B。回到调用函数（创建实例的函数）中，实例的A和B将具有被调用方法赋予它们的值。

现在，您使它成为一个结构。该属性仍然可变。您可以使用与以前相同的语法执行相同的操作，但是现在，调用该方法之后，实例中不再存在A和B的新值。发生了什么？好了，您的类现在是一个结构，这意味着它是一个值类型。如果将值类型传递给方法，则默认值（不带out或ref关键字）将传递“按值”；创建实例的浅表副本以供该方法使用，然后在方法完成时销毁该副本，而保留初始实例的完整性。

如果将引用类型作为结构的成员，这将变得更加令人困惑（这是不允许的，但实际上在所有情况下都是极差的做法）；不会克隆该类（仅复制结构的引用），因此对结构的更改不会影响原始对象，但是对结构的子类的更改将影响调用代码中的实例。这很容易使可变结构处于非常不一致的状态，从而可能导致距实际问题很远的地方出错。 ;允许使用者仅在构造对象时指定属性的值，而从不提供任何更改该实例的值的方法。只读字段或仅获取属性是规则。如果消费者想要更改值，则他们可以基于旧对象的值创建一个新对象，并带有他们想要的更改，或者可以调用将执行相同操作的方法。这迫使他们将您的结构的单个实例视为一个概念上的“值”，该值与其他结构不可分割且有区别（但可能等同）。如果他们对您类型存储的“值”执行运算，则会获得一个新的“值”，该值不同于其初始值，但仍具有可比性和/或语义上相等。

举一个很好的例子，看看DateTime类型。您不能直接分配DateTime实例的任何字段。您必须创建一个新实例，或者在现有实例上调用将产生一个新实例的方法。这是因为日期和时间是“值”，例如数字5，更改数字5会导致新值不是5。仅仅因为5 + 1 = 6并不意味着5现在是6因为您添加了1。 DateTimes的工作方式相同；如果增加一分钟，则12:00不会“成为” 12:01，而是获得一个新的值12:01，该值不同于12:00。如果这是您所用类型的逻辑状态（.NET中未内置的良好概念示例，例如Money，Distance，Weight和UOM的其他数量，其中操作必须考虑值的所有部分），然后使用结构并进行相应的设计。在大多数情况下，对象的子项应该独立可变，请使用类。

#2 楼

答案：“对于纯数据结构使用结构，对带有操作的对象使用类”绝对是错误的IMO。如果一个结构拥有大量的属性，那么一个类几乎总是更合适。从效率的角度来看，Microsoft经常说，如果您的类型大于16个字节，则应该是一个类。 -net-struct小于16个字节

#3 楼

class和struct之间最重要的区别是在以下情况下发生的情况：如果thing1.somePropertyOrField是一个结构，而Thing是一个公开的公共字段，则对象somePropertyOrField和thing1将彼此“分离”，因此后面的语句不会影响thing2。如果thing1是一个类，则Thing和thing1将彼此连接，因此后面的语句将写thing2。在前一种语义更有意义的情况下，应该使用一个结构，而在后一种语义更有意义的情况下，应该使用一个类。

请注意，尽管有人建议使某事物可变为参数是有利于它成为类的，我建议相反的说法是正确的：如果为了保存某些数据而存在的某物体将可变，并且是否附加实例则不明显对于任何事物，事物都应该是一个结构体（可能具有暴露的字段），以使实例没有附加到其他事物上。

例如，考虑以下语句：

  Thing thing1 = new Thing();
  thing1.somePropertyOrField = 5;
  Thing thing2 = thing1;
  thing2.somePropertyOrField = 9;

第二条语句会改变存储在thing1.somePropertyOrField中的信息吗？如果myPeople是一个暴露场结构，它就不会，而且事实并非如此，这显然是因为它是一个暴露场结构；如果Person是一个结构并且希望更新Person，则显然必须做类似myPeople的操作。但是，如果myPeople.UpdatePerson("123-45-6789", somePerson)是一类，则确定上面的代码是否永远不会更新Person的内容，始终更新它，或者有时更新它可能要困难得多。

关于结构应该是“不变的”的观点，我总体上不同意。对于“不可变的”结构，存在有效的使用情况（在构造函数中强制执行不变式），但要求在其任何部分更改笨拙，浪费且更容易引起错误的情况下，必须重写整个结构，而不仅仅是暴露字段直接。例如，考虑一个MyPeople结构，其字段包括PhoneNumber和AreaCode，并且假设其中一个具有Exchange。以下内容的效果应该很清楚：如果List<PhoneNumber>是所谓的“不可变”结构，则有必要为每个字段提供PhoneNumber方法，该方法将返回一个新的结构实例，该实例在指定字段中保留传入的值，否则它将对于像上面的代码来说，了解结构中的每个字段都是必需的。


顺便说一句，至少在两种情况下，结构可能合理地持有对可变类型的引用。


结构的语义表明它是存储有关对象的标识，而不是作为保存对象属性的快捷方式。例如，“ KeyValuePair”将保存某些按钮的标识，但不会保留有关这些按钮的位置，突出显示状态等的持久性信息。

该结构知道它保存了仅引用该对象，没有其他人会获得引用，并且对该对象执行的任何突变都将在对该对象的引用存储到任何地方之前进行。


在在前一种情况下，对象的IDENTITY将是不可变的；在第二种方法中，嵌套对象的类可能不强制不变性，但是保存引用的结构将实现。

#4 楼

我倾向于仅在需要一种方法时才使用结构，从而使类显得“过重”。因此，有时我将结构视为轻量级对象。注意：这并不总是可行，也不总是最好的做法，因此它确实取决于情况！ ：http://msdn.microsoft.com/zh-cn/library/ms229017.aspx
此链接验证了我上面提到的内容，结构仅应用于容纳少量数据。

#5 楼

对于纯数据结构，请使用结构，对于具有操作的对象，请使用类。这很明显所有结构都是数据的容器。

如果您的结构具有以任何更复杂的方式修改结构的操作，请使用类。一个类也可以通过方法的参数与其他类进行交互。

将其视为砖头和飞机之间的区别。砖是结构。它具有长度，宽度和高度。它做不了什么。一架飞机可能会进行多种改变操作的操作，例如移动控制面和改变发动机推力。最好还是上课。