Negative tive C # use the new modifier only when the new base class causes problems

We generally use the new modifier on Class Members to redefine non-Virtual members inherited from the base class. This does not mean we should do this. Redefinition of non-virtual methods can lead to ambiguous behaviors. For example Code The vast majority of developers think that their behavior is the same (assuming that two classes have an inheritance relationship ):

Object C = Makeobject ();

// Call through myclass reference:

Myclass Cl = C As Myclass;

Cl. magicmethod ();

// Call through mytherclass reference:

Mytherclass Cl2 = C As Myotherclass;

Cl2.magicmethod ();

 

If the new modifier is used, this is not the case:

 

Public   Class Myclass

{

Public VoidMagicmethod ()

{

//Ignore details.

}

}

Public   Class Mytherclass: myclass

{

// Redefine magicmethod.

Public   New   Void Magicmethod ()

{

//Ignore details.

}

}

 

This will lead to many ambiguous places. If the same function is called on the same object, we expect the same code to be executed. But the fact is that if we change the reference for calling a function, the function call behavior will also be different. This inconsistency seems ridiculous. A mytherclass object has different behaviors because of its different references. The modifier new does not change a non-virtual method to a virtual method. Instead, it adds a different method to the class.

The non-virtual method is static binding. Any reference to myclass. magicmethod ()Source codeThis method is used for all calls. The system does not search for other versions defined in the derived class at runtime. On the other hand, virtual functions use dynamic binding. The system selects to call the correct function based on the object runtime type.

Avoiding the use of the new modifier to redefine non-virtual functions does not mean that all functions in the base class should be defined as virtual functions. WhenProgramWhen the library designer defines a function as a virtual function, it actually enters into a contract for the type: that is, any derived class can change the implementation of the virtual function. In fact, the virtual function set defines all the behavior that may change in the derived class. The "virtual by default" design indicates that the derived class can change all behaviors of the class. This means that we have not carefully thought about what behavior the derived class will change. We should not do this. Instead, we should take time to carefully consider which methods and attributes should be declared as polymorphism members. We should declare them as virtual members only. Do not consider this practice as a restriction on class users. On the contrary, this approach should be considered to provide some entry points for custom type behaviors.

There is only one case where we need to use the new modifier, that is, after we use the new base class, the added method name conflicts with the currently used method name in the subclass. Because the Code already has the existing method name in the dependent subclass, for example, another assembly may be using this method. For example, we defined the new mywidget class by inheriting the basewidget defined in another library:

 

Public   Class Mywidget: basewidget

{

Public VoidDowidgetthings ()

{

//Ignore details.

}

}

 

Assume that after mywidget is completed, a customer is using it. Then we found that basewidget released a new version of basewidget. Thanks to our Ardent expectation for new features, we immediately purchased it and tried to generate a new version of mywidget. However, it fails to be generated because basewidget has added its own dowidgetthings method.

 

Public   Class Basewidget

{

Public VoidDowidgetthings ()

{

//Ignore details.

}

}

 

This is a problem. Our base class quietly introduces a method with the same name as the subclass. There are two ways to fix this problem. First, we can change the dowidgetthings Method Name:

 

Public   Class Mywidget: basewidget

{

Public VoidDomywidgetthings ()

{

//Ignore details.

}

}


Alternatively, we can use the new modifier:

Public   Class Mywidget: basewidget

{

Public New VoidDowidgetthings ()

{

//Ignore details.

}

}

 

 

If you can access all the client code of the mywidget class, we should choose to change the method name, because it is more convenient in the long term. However, if our mywidget class is released all over the world, it will force all customers to make numerous changes. This is the application of the new modifier. Our customers can continue to use the dowidgetthings () method without any changes. They will not call basewidget. dowidget-things (), because such a call cannot exist in the Customer Code. The modifier new is used in this scenario: the members added to the new base class conflict with those already declared in the subclass.

Of course, over time, our users may also try to use the basewidget. dowidget-things () method. At this time, we go back to the original problem: the two methods look the same, but actually they are different. Therefore, we should consider the long-term adverse effects of the new modifier. Sometimes it is worthwhile to change the method name in the short term.

In conclusion, you must be careful when using the new modifier. If it is used indiscriminately, ambiguous method calls will appear on the object. We should consider using the new modifier only when there is a conflict between the members added to the new base class and existing members in the subclass. Even in this case, we should consider it carefully before using it. In addition, we should not use the new modifier in any other circumstances.