VB.NET: is using Structures considered nasty?_问答_开发者

开发者_JAVA技巧

I use to use Structures quite a lot in the VB6 days, and try to avoid them now with .NET. Just wondering if using structures in 2010 instead of a Class is considered nasty?

Thanks for the help.

Choosing a Structure takes consideration instead of being inherently "nasty". There are reasons why a Structure can be nasty; however there are also reasons a Class can be nasty in its own way...

Basically when you decide between these two object oriented kinds of containers, you're deciding how memory will be used.

There are different semantics associated with Structure and Class in VB.NET and they represent different memory usage patterns.

By creating a Class you're creating a reference type.

good for large data
memory contains a reference to the object location on the heap (like the concept of pointing to an object) though happens transparently to the VB.NET programmer because you're in "managed mode".

By creating a Structure you're creating a value type.

good for small data
memory allocated contains the actual value
be judicious because these are apt to get pushed on the stack area of memory (i.e. for local vars, but not class fields) - too large and you could run into stack issues.

Also some good video resources on YouTube if you're an audio learner.

Many articles on the Internet like these MSDN articles to teach the basics and details:

Value Types and Reference Types
7.1 Types - Reference and Value
MSDN Type Fundamentals - subheading: Reference and Value Types

Example

VB.NET: is using Structures considered nasty?

Structures exist because in some scenarios they make more sense than classes. They are particular useful for representing small abstract data types such as 3D points, latitude-longitude, rational numbers, etc.

The basic motivation for using structs is to avoid GC pressure. Since structs live inline (on the stack or inside whatever container you put them in) rather than on the heap, they typically result in far fewer small allocations, which makes a huge difference if you need to hold an array of one million points or rationals.

A key issue to watch out for is that structs are value types, and thus are generally passed around by value (the obvious exception being ref and out parameters). This has important implications. For instance:

Point3D[] points = ...;
points[9].Move(0, 0, 5);

The above code works fine, and increases the z coordinate of the 10th point by 5. The following code, however:

List<Point3D> points = ...;
points[9].Move(0, 0, 5);

Will still compile and run, but you will find that the z coordinate of the 10th point remains unchanged. This is because the List's index operator returns a copy of the point, and it is the copy that you are calling Move on.

The solution is quite simple. Always make structs immutable by marking all fields readonly. If you still need to Move points around, define + on the Point3D type and use assignment:

points[9] = points[9] + new Point3D(0, 0, 5);

It's considered pretty bad to use anything without understanding the implications.

Structures are value types, not reference types - and as such, they behave slightly differently. When you pass a value type, modifications are on a copy, not on the original. When you assign a value type to an object reference (say, in a non-generic list), boxing occurs. Make sure you read up on the full effect of choosing one over the other.

Read this for some understanding benefits of structures vs classes and vice-versa.

A structure can be preferable when:

You have a small amount of data and simply want the equivalent of the UDT (user-defined type) of previous versions of Visual Basic

You perform a large number of operations on each instance and would incur performance degradation with heap management

You have no need to inherit the structure or to specialize functionality among its instances

You do not box and unbox the structure

You are passing blittable data across a managed/unmanaged boundary

A class is preferable when:

You need to use inheritance and polymorphism

You need to initialize one or more members at creation time

You need to supply an unparameterized constructor

You need unlimited event handling support

To answer your question directly, there is nothing inherantly wrong with using a structure in VB.NET. As with any design decision you do need to consider the consequences of this decision.

It's important that you're aware of the difference between a class and a structure so that you can make an educated decision about which is appropriate. As stated by Alex et al, one of the key differences between a structure and a class is that a structure is considered a value type and a class is considered a reference type.

Reference types use copy-by-reference sematics, this means that when an object is created or copied, only a pointer to the actual object is allocated on the stack, the actual object data is allocated on the heap.

In contrast, value types have copy-by-value sematics which means that each time a value type (e.g. a structure) is copied, then the entire object is copied to a new location on the stack/

For objects with a small amount of data, this isn't really a problem, but if you have a large amount of data then using a reference type will likely be less expensive in terms of stack allocations because only a pointer will be copied to the stack.

Microsoft have guidelines on the use of structures that more precisely describe the differences between classes and structures and the consequences of choosing one over the other

From a behavioral standpoints, there are three types of 'things' in .net:

Mutable reference types
Value types which can be mutated without being entirely replaced
Immutable reference and value types

Eric Lippert really dislikes group #2 above, since .net isn't terribly good at handling them, and sometimes treats them as though they're in group #1 or #3. Nonetheless, there are times when mutable value types make more sense semantically than would anything else.

Suppose, for example, that one has a rectangle and one wants to make another rectangle which is like the first one, but twice as tall. It is IMHO cleaner to say:

  Rect2 = Rect1       ' Makes a new Rectangle that's just like Rect1
  Rect2.Height = Rect2.Height*2

than to say either

  Rect2 = Rect1.Clone  ' Would be necessary if Rect1 were a class
  Rect2.Height = Rect2.Height*2

  Rect2 = New Rectangle(Rect1.Left, Rect1.Top, Rect1.Width, Rect1.Height*2)

When using classes, if one wants an object that's slightly different from an existing object, one must consider before mutating the object whether anyone else might want to use the original; if so, one must make a copy of it and then make the desired changes to the copy. With structs, there's no such restriction.

A simple way to think of value types is to regard every assignment operation as making a clone of the original, but in a way that's considerably cheaper than cloning a class type. If one would end up cloning a lot of objects as often as one would assign references without cloning, that's a substantial argument in favor of structs.