Design Guidelines in C#.NET

Encode PDF417 in C#.NET Design Guidelines

You should use structs only for types that are really just pieces of data for types that could be used in a similar way to the built-in types. A type, for example, is like the built-in type decimal, which is implemented as a value type. Even if more complex types can be implemented as value types, they probably shouldn t be, since the value type semantics will probably not be expected by the user. The user will expect that a variable of the type could be null, which isn t possible with value types.

Value types nicely result in value semantics, which is great for types that feel like data. But what if it s a type that needs to be a class type for implementation reasons but is still a data type, such as the string type To get a class to behave as if it were a value type, you need to write the class as an immutable type. Basically, an immutable type is one designed so that it s not possible to tell it has reference semantics for assignment.

CHAPTER 9 STRUCTS (VALUE TYPES)

Consider the following example, with string written as a normal class: string s = "Hello There"; string s2 = s; s.Replace("Hello", "Goodbye"); Because string is a reference type, both s and s2 will end up referring to the same string instance. When that instance is modified through s, the views through both variables will be changed. The way to get around this problem is simply to prohibit any member functions that change the value of the class instance. In the case of string, member functions that look like they d change the value of the string instead return a new string with the modified value. A class where there are no member functions that can change or mutate the value of an instance is called an immutable class. The revised example looks like this: string s = "Hello There"; string s2 = s; s = s.Replace("Hello", "Goodbye"); After the third line has been executed, s2 still points to the original instance of the string, and s now points to a new instance containing the modified value.

The following code defines the interface IScalable and the class TextObject, which implements the interface, meaning that it contains implementations of all the functions defined in the interface: public class DiagramObject { public DiagramObject() {} } interface IScalable { void ScaleX(float factor); void ScaleY(float factor); } // A diagram object that also implements IScalable public class TextObject: DiagramObject, IScalable { public TextObject(string text) { this.text = text; } // implementing IScalable.ScaleX() public void ScaleX(float factor) { // scale the object here. } // implementing IScalable.ScaleY() public void ScaleY(float factor) { // scale the object here. }

private string text; } class Test { public static void Main() { TextObject text = new TextObject("Hello"); IScalable scalable = (IScalable) text; scalable.ScaleX(0.5F); scalable.ScaleY(0.5F); } } This code implements a system for drawing diagrams. All the objects derive from DiagramObject, so they can implement common virtual functions (not shown in this example). Some of the objects can be scaled, and this is expressed by the presence of an implementation of the IScalable interface. Listing the interface name with the base class name for TextObject indicates that TextObject implements the interface. This means TextObject must have functions that match every function in the interface. Interface members have no access modifiers, and the class members that implement the interface members must be publicly accessible. When an object implements an interface, a reference to the interface can be obtained by casting to the interface. This can then be used to call the functions on the interface. This example could have been done with abstract methods, by moving the ScaleX() and ScaleY() methods to DiagramObject and making them virtual. The Design Guidelines section later in this chapter discusses when to use an abstract method and when to use an interface.