Valid tive C # item 28: avoid conversion Operators

Valid tive C # item 28: avoid conversion Operators

The conversion operation provides a replaceable relationship between classes. This means that the object of a class can be replaced by other class objects. The advantage is that the object of a derived class can be replaced by the object of its base class. We can refer to the structure. We create a shape base class and three Derived classes: Circle, ellipse, and square. In any case, circle can be used to replace shape, because circle is a special shape, which is a manifestation of polymorphism. Just as in. net, any object can be replaced by a system. Object object, which is a base class of all types. Similarly, the object of the class we created may be replaced by the class that implements the same interface, the class that implements the same base class interface, or the object of the base class.

If we need to define a conversion operation for the class, it indicates that it may be replaced by other target types. Such replacement often leads to some potential errors, often because the conversion between two types is not perfect. In addition, in terms of efficiency, the efficiency of modifying the target type is often low, especially when the conversion generates a temporary object. In addition, the conversion rules are based on the type objects in the compilation period, rather than the runtime. Users may need to use multiple forced type conversions to implement this substitution relationship, which may make the code difficult to maintain.

If you really need to convert one type to another target type, we should implement it through the constructor. This will make the operations for creating new objects clearer. Implicit conversions often cause some difficult-to-find errors. Suppose we have a class structure. Three Child classes are generated from the base class. We know that every circle is an elliptic, and some special ovans are circles. Although there is a relationship between the circle and the ellipse, we still design the structure like this, this is because we do not want to have non-Abstract leaf classes in the structure (otherwise, the structure here should be HAPE-> ellipse-> circle ). Since every circle is an elliptic, we can add a new elliptic transformation created from the circular:

Class circle: Shape
{
Private pointf _ center;
Private float _ radius;

Public circle (pointf C, float R)
{
_ Center = C;
_ Radius = R;
}

Public circle ()
: This (pointf. Empty, 0)
{
}

Static public implicit operator ellipse (Circle C)
{
Return new ellipse (C. _ center, C. _ center, C. _ radius, C. _ radius );
}
}

Now we can use the circle in any place where ellipse can be used. This conversion will automatically happen:

Public double computearea (ellipse E)
{
// Calculated area
}

Circle C = new circle (New pointf (3.0f, 3.0f), 5.0f );
Computearea (C );

The above example shows how a circle is converted into an elliptic. The computearea function can also run normally after conversion. But it's just luck. Let's look at the following function:

Public double flatten (ellipse E)
{
E. R1/= 2;
E. R2 * = 2;
}

Circle C = new circle (New pointf (3.0f, 3.0f), 5.0f );
Flatten (C );

At this time, the program will not be able to play a role. Since the flatten () method uses an ellipse as a parameter, the compiler requires that we provide a conversion to convert a circle into an elliptic. This conversion can provide an elliptical temporary object as a parameter for the flatten () function when we call it. This temporary object will be modified by the flatten () function and then destroyed immediately. The operations we expected did not occur on the original Circle C, but on the temporary object.

Since implicit conversion does not work, we continue to try to use explicit forced type conversion:

Circle C = new circle (New pointf (3.0f, 3.0f), 5.0f );
Flatten (ellipse) C );

This does not solve the fundamental problem. We also created a temporary object. Circle C will not change. Next, we will try to use the ellipse constructor to achieve the conversion purpose:

Circle C = new circle (New pointf (3.0f, 3.0f), 5.0f );
Flatten (New ellipse (c ));

Most programmers can see at a glance that the above Code will not achieve the goal. All modifications made in the flatten () function are lost. We can fix the error as follows:

Circle C = new circle (New pointf (3.0f, 3.0f), 5.0f );
Ellipse E = new ellipse (C );
Flatten (E );

Variable e is the modified elliptic. By using constructors to replace conversions, the object creation process is clearer.

The object attribute returned by the conversion operation may lose some of its original behaviors, which may cause us some trouble. Through the conversion operation, some client programs may access the internal members of the object. This is something we need to avoid.

Conversion operations may cause some problems during programming. When users expect other types to replace our original types, we should be clear that this conversion produces a temporary object that will soon be destroyed. Because the compiler automatically generates this conversion code, it is difficult to find the hidden bug. Therefore, if conditions permit, we should avoid conversion operations as much as possible.

Translated from Objective C #: 50 specific ways to improve your C # by Bill Wagner

Back to directory