Re-learn. Net [8] -- CLR object-oriented implementation

After a few days of laziness, I tried my best. Well, just a few years ago, I wrote a little more ^_^.

One of the goals of. NET is to build an object-oriented programming platform. Of course, CLR must support all the features of object-oriented. Specifically, CLR can basically be regarded as a fully object-oriented platform (recall the previously mentioned CTS ). CLR Object-oriented has its own characteristics and implementation methods. Below we will write a little bit about it, which is very sporadic and unsystematic. It is a note.

Encapsulation:
CLR has no special support for encapsulation. It is still public, private, and protected (Here we use the C # syntax instead of the CLR syntax for your understanding, the same below). Some special permissions include internal, which expands the permissionsProgramSet level, I rarely use it, and I feel bad about it ^_^. It is worth noting that the interface is used to skillfully implement functions similar to youyuan. If you are interested, you can check the C # method to implement the notepad mode.

Abstraction:
In CLR (C # syntax is used below), virtual base classes are supported (abstract class, which cannot be instantiated and can only be used as a base class) and interfaces ). There is a basic principle in the design pattern: interface-oriented programming. I personally think that the interface mentioned here is reflected in C #, not just interface, but all abstract means, including abstract class and interface. In many cases, we should give priority to the virtual base class instead of the interface. Abstract class has better modifyability. For example, you provide an abstract class and interface called Superman. At the beginning, it only had one fly method. Then I want to add a Walk Method for him (Superman is also a human, and cannot fly every day ). At this time, if you use abstract class, you only need to add a walk with the default implementation. If it is implemented by interface, you must not only change the interface, you also need to modify all types that implement the interface (of course, sometimes this is better and safe ). A well-known empirical principle is the is-a and can-do principles. If the subclass is a part of the base class, use abstract class. If the base class is only a function of the subclass, use interface. In contrast, the interface has higher design requirements. You must ensure that it will not be changed, otherwise it will be very painful.
back to the interface-oriented programming principles in the design model, Jin yuliangyan is indeed, but cannot be forced. Sometimes you do not need to abstract it. In practice, there is also a very effective principle that must comply with is to use the most abstract interface for communication as much as possible. Consider the following two functions:
Public ilist getlist ();
Public arraylist getlist ();
If the previous function can meet your needs, never use the second one. Higher abstraction means lower communication costs and higher change support. For example, one day I hate to use the default arraylist to implement my functions, and I implement ilist myself. So all the functions using the second function need to be modified. This is a terrible thing and should be avoided as much as possible.

polymorphism:
the CLR layer provides comprehensive support for polymorphism. It supports function polymorphism of different parameter numbers, different parameter types, and different return values. However, in terms of language, such as C #. It only supports overloading of different parameter types or quantities.
in practical applications, we should try to replace the default parameter with polymorphism, and put the specific implementation of the function in the function with the longest parameter column, other functions call this function. For example:
Public void themethod (int A, int B, string s) {// Implementation}
Public void themethod (int A, int B) {themethod (a, B, "") ;}< br> this can also be used to check whether you use polymorphism correctly. For example, if you have a themethod (int A), you cannot call themethod (int A, int B, string s) as its implementation, you should consider the name of your function and remove it from your polymorphism system.

Inheritance:
Inheritance is one of the most effective and troublesome methods in object-oriented systems. It is really not easy to make good use of inheritance. CLR does not support multi-inheritance. You can use the inheritance interface to meet the requirements of Multi-inheritance. This reduces the complexity of inheritance. Another important principle in the design model is to prioritize combination rather than inheritance. It is also an unquestionable statement. It is very important to learn to use inheritance correctly.
An important part of inheritance is function rewriting. CLR has its own virtual function implementation mechanism. It uses metadata to dynamically parse virtual functions, whether or not your subclass is constructed, it has the function of calling the class functions in the deepest inheritance system. If you are familiar with C ++, be sure to clearly distinguish it from C ++. (C ++ uses virtual tables for Dynamic Construction. In the CLR, metadata is used for identification and dynamic parsing. It is not easy to clarify the differences. You can try to write down the followingCode:
Public abstract class base
{
Public base ()
{
Method ();
}

Public abstract void method ();
}

Public class derived: Base
{
Private int value;
Public derived ()
{
Value = 1;
}

Public override void method ()
{
If (value = 1)
{
Console. writeline ("OK ");
}
Else
{
Console. writeline ("wrong ");
}
}
}
Then, instantiate a derived object to see if it can be compiled and whether the running results are consistent with expectations. It can also be transplanted to C ++ for implementation. You may have unexpected discoveries and a better understanding of this mechanism.
Understanding this situation helps you to correctly use virtual functions in constructors. Maybe you won't write code similar to the code above next time.
Together with function overloading, it must be noted that the function is hidden. If the base class does not indicate that the function is a virtual function, a function with the same name in the subclass will hide the function with the same name in the base class. You can use the new keyword (in C #) to place it in front of the function and tell the compiler clearly. Yes, I just want to hide it. Note that the code similar to the following is also considered hidden:
Virtual void themethod () // In the base class
Void themethod () // subclass
You need to add the overide keyword before the subclass function to tell the compiler that I want to rewrite rather than hide it.

Others:
There are many things to be aware of in OO programming. For example, the default constructor, value passing and address passing, and static class. The above is just a simple summary. To learn more details, you need to read more books, practice more, and think more. I hope everyone can make common progress together.