Let us feel the out and in, outin of the generic interface with great care

Let us feel the out and in, outin of the generic interface with great care

The out and in keywords are familiar to everyone. F12 has seen many generic types defined by the system. However, it is rarely used in practice. It was previously seen in the Redbook that two or three pages were covered. Some concepts are directly moved out. They just say what the writing will do and why the image is not designed and useful. In addition, the meaning of translation is very stiff and hard to understand. Naturally, Baidu once again, reading a lot of people's opinions, this is still like a low-resolution image, not clear enough. In fact, all kinds of knowledge points now basically know what is going on and how to use it, but there is always little or no high definition. As a result, I recently wrote a console to hide all kinds of knowledge points that are not high-definition or need to be displayed. Sure enough, I have to get a glimpse of it on the paper. I want to know how to write code. A lot of things can be tried once or used together. It is indeed refreshing. Many designs know the reason and the world is full of high definition. Not much nonsense. Share your humble opinions that are simple, rude, and effective.

Since it is a generic out in keyword (not a generic one has been tried), write it. Therefore

It can only be used for interfaces and delegation generics.

Sure enough, OK. Why can I only use interfaces and Delegation? I can't figure it out at half past one. I don't need to worry about it first, and I will try again. I wrote a bunch in the Redbook. It doesn't matter if I don't understand it, but it's a key point,The generic type modified by in can only be input parameters, and the out type can only be returned.. The problem comes again. Why is this design so hard to figure out? Don't worry about it, verify it, And then renew it.

Correct the error. Now a generic interface has the in and out keywords defined. What can an interface do? implement it. To implement the generic interface, you must specify the generic type as the specific type. The Redbook introduces a bunch of topics,In and out are related to type conversion. Here, in and out must be effective only when it is applied to the parent class subclass.Define a parent class and a subclass, and then implement the interface.

During implementation, the in out type can be specified at will, as long as the in parameter is satisfied, and the out parameter is the return type. Since it can be written in this way, that's it. In the Redbook, I wrote how to convert the classes that implement interfaces after using in, and how to convert the classes after using out. There are a lot of things around. The focus is on implementation,The parent subclass can be used as a wildcard type.. Let's let him go.

Now GT_ClassC inherits from GT_InterfaceC <GT_Child, GT_Parent>, so the write is OK.

Since the parent class subclass implements different conversions for generics, we can modify the parent class or subclass generics on the left to see if they can be converted. First, change the Child class on the left to the parent class, which is the generic interface implemented by the two parent classes.

The result cannot be automatically converted. Why is an error reported when the parameter on the left changes from the subclass to the parent class.

　　First, the in modifier is on the left. Therefore, the wildcard on the left must be of the input parameter type. Let's take a look at what is the input parameter of the Show method of the GT_ClassC class, which is a subclass of GT_Child, right? Assume that the method body has already called a member of the subclass, at this time, we will change the input parameter type to its parent class. What is the problem. The sub-classes do not necessarily have parent classes. This is the key, and the method body has an exception risk. Therefore, the input parameter type can only be compatible with the class or subclass of GT_Child.

Whether it is out of breath. When the type modified by in is converted to each other after the implementation of the generic interface, the type on the Left can only be the same type or subclass of the type on the right. Let's look at the description of the in Variable Resistance in the Redbook to take a look at the conversion from the parent class to the subclass (who can understand this). in fact, it means that the type modified by in can only be backward compatible, the compiler can be converted to a subclass.

Let's take a look at out. out is the second modifier of the GT_InterfaceC type. So we can modify the second parameter in the no-error method just now, so

Indeed, an error is reported. Let's just try again.

The Type modified by the out keyword can only be the return type. SeeCheck the return type of the Show method in GT_ClassC.What is GT_Parent, right. Why is an error reported when the out type on the left is changed from the parent class to the subclass. In combination with the above understanding, because this type must be the return type, assuming that the returned is a parent class, what will happen to convert the parent class to a subclass. View lab results

The conversion from the parent class to the Child class cannot be implicitly converted because the parent class can have multiple child classes, and the conversion must be forcibly converted. Therefore, the return type of the Show method can only be implicitly converted to the parent class.

Is it coming soon:When the out type is converted to each other after the implementation of the generic interface, the type on the Left can only be the same type or parent class of the type on the right. Simply put, the out type can only be compatible with up.And in is really a forward call. Looking back, if in and out are not limited: in can only modify the input parameter type, and out can only modify the return type. Is it true that the above theory, now I know why there are such constraints.

The following is a summary of the code written to help you understand it.

In fact, at the beginning, GT_ClassC implemented the interface type. The type of in out is reversed from the current figure. As a result, someone should think of it, no matter what type is on the left, conversion is successful on the right. At the beginning, it was okay for me to replace the parent class of the left sub-class. I thought that I could write it as long as I used the in out constraint, but I immediately felt a strange thing. If there is no problem, let's talk about the covariant resistance. Let's talk about the in constraint of the input parameter, and the out constraint of the return type. So we have the above inferences.

 

Check whether it is enough. Too young, simple is good.

Let's look back at the first question: why can I use in out only for generic interfaces or generic delegation. Let's write two lines of code.

Defining a simple generic type does not work no matter how it is converted.

Generic ConversionIs based on the interface, no matter what the specific implementation type is, two members of the same generic interface can of course convert. The specific type conversion is based on the in and out constraints. (If the type on the left and right is not an inheritance relationship, an error is returned. We have already performed this experiment ).

Let's look at the delegation,A delegate can be understood as a type that defines (specify the parameter type and the return type method. Is it similar to generics? An event is equivalent to delegate implementation, and is there a shadow of a generic interface.

Generic DelegationWhen it comes to generics, there are input parameters and return types. Of course, you can use in out to constrain generics to achieve (generic delegation achieves mutual conversion) compiler checks.

The following is a complete demo for you to view. Some Error-Checking code has been deleted. If you are interested, write it yourself.