Structures and Identity

Question

As stated in the MSDN documentation and elsewhere, the structure does not have an identifier and therefore should have an “eternal” value that never changes, such as a phone number (the phone number does not change, but you get a new one).

How can this affect my coding decisions?

Based on this knowledge, I am right in thinking that no identification means that if two structures have the same data, there is no way to tell them separately, so that conceptually they are one and the same. Thus, the two structures used in the code base for a number, for example (7), are always the same. Thus, with classes two objects with the same data (for example, a person object with a single name) can be different people, but with the help of structures this difference does not exist. Thus, the structure, which can be a skill (for example, fishing), will always be the same (there is no identifier to distinguish it).

Hope this makes sense.

thanks

Answer 1

A string is a value. A class is an object. This is very similar to real life, where 42 will always be equal to 42, but you can have two people named John Smith.

What you said in the question is a very good outline of value type concepts compared to reference types.

As for how this should affect your coding, always specify the code so that the value equals the same value, for example. 42 should always be 42. There are cases when the reference type should be compared by value instead of identifier (for example, a string). But in most cases, reference types are compared by identity.

If you can measure or calculate it, it is a type of value. Otherwise, use a reference type.

Answer 2

Structures share most of the same syntax as classes , but according to MSDN :

Type of structure suitable for representing light objects

The key difference between the two is that Classes generate objects of a reference type, and Structures generate objects of a value type, which means that the following operation:

Point A = new Point(); Point B = A; 

Will make A and B access the same object in memory if Point is a class, or create a new copy of A and assign it to B if Point is Struct.

In the case where Point is Struct, the following relations are true:

 Object.Equals(A,B) == true Object.ReferenceEquals(A,B) == false 

Therefore, you can select them separately , and two structures are not the same thing , because each of them is an object in memory.

This SO question discusses when Structs is recommended.

Answer 3

The concept of "structure" or "record" was created before the concept of "class". And sometimes they can be changed.

When to use a variable, field or instance of a structure:

(1) When only data members are needed, without methods. Or has several methods that are barely used, such as constructors.

Example:

 struct CoordinateStruct { int X; int Y; } 

(2) When a large number of elements are required, and since objects use additional memory and are sometimes not visible, methods are transferred to the container element, such as another object, an object (namespace), such as an object, or a singleton object (Flyweight Design Template).

Before:

 class PointClass { int X; int Y; // its also an object / class Color Color; public void assign(int NewX, int NewY, Color NewColor) { ... } public void move(int addX, int addNewY) { ... } } // multiple element container class CADAppClass { List<Point> Points; // ... } // Not enough memory Exception !!! 

After:

 struct PointStruct { int X; int Y; // its a low memory integer int Color; } // multiple element container class CADAppClass { List<Point> Points; public void assignPoint (ref PointStruct Point, int NewX, int NewY, Color NewColor) { ... } public void movePoint (ref PointStruct Point, int addX, int addNewY) { ... } // ... } 

(3) When you need to encapsulate data elements, even if it is a small number of elements in a variable, even if there are methods, operators, events, or "messages". Encapsulation, possibly for serializacion as an example (loading from DLL, DCOM, JSON, files with ordinary data).

Before:

 class CustomerClass { String FirstName; String LastName; public void Store(Stream Destination) { ... } public void Load(Stream Source) { ... } public void CopyTo(CustomerClass Destination) { ... } public void CopyFrom(CustomerClass Source) { ... } } 

After:

 struct CustomerStruct { char[100] FirstName; char[100] LastName; } // one to one, nested, relationship, seems redudant, // but required Class CustomerClass { CustomerStruct Data; public void Store(Stream Destination) { ... } public void Load(Stream Source) { ... } public void CopyTo(CustomerStruct Destination) { ... } public void CopyFrom(CustomerStruct Source) { ... } } 

I used this one, with enumerations instead of structures, in programming languages ​​oriented to objects and classes, but which do not treat enumerations as objects (like object oriented PHP and Object Pascal) like Java or C # does.

(4) A mixture of previous cases or scenario is not considered.

Greetings.