C # static and dynamic combination of programming three: Duck Typing

Mean

C # is a static type language, and you must reference the definition of that type to use the type. Therefore, the referential dependencies between components occur from the software organization perspective. There are two modes of common reference dependencies:

A. Forward dependency: Component A uses the class T defined in component B, component A directly refers to component B, and the dependency is "component A-> component B".

B. Reverse dependency: Component A defines the functional specification through interface I, for abstract programming; component B in turn refers to component A and defines the class T implementation interface I, and the other component C glues I to t, and the dependency is "component A <-component B". This is the famous IOC way.

In short, the IOC is "who has the norm, who has control, who enforces the specification and who is controlled". If the specification is based on static type checking of C #, such as interfaces or abstract classes, then the specification shows a strong grammatical constraint, making component a more independent, while component B is subject to component A.

The first article in this series, with an interface based IOC example, we see that when a third-party component is needed, in order to apply the static type constraints of the interface, an additional adapter is required to implement the interface and to wrap the invocation of the third party component. This shows that the interface-based IOC is less flexible in bonding specifications and implementations.

However, there is no inevitable connection between the specification and the type constraint. In the case of the Commission based IOC, we do not need any adapter, we can easily glue the specification and implementation, showing a strong flexibility. This is the definition of a specification through a delegate, which does not cause component B to be dependent on component A, and the implementation of component A and component B appears to be relatively independent.

In fact, we can have more flexible specifications than delegates, such as: to express the specification through HTTP + XML, which is even language-independent, it is entirely possible that component A is written by C # and component B is written by Java.

The 3 specification definitions listed above are defined in terms of interfaces, delegates, HTTP + XML, respectively, from constraints to protocols, and 3 styles from strict to flexible. There are, of course, many more ways, but here are just a few of the three types of delegates. Between the movement and the static need to grasp a sense of propriety, interfaces are too rigid, while HTTP + XML is entirely based on runtime protocols, and requires a lot of checking; the benefit of delegates is that they eliminate the dependencies of component A and B, and enjoy the benefits of IDE smart hints and compiler checks (signature checks). Therefore, the entrustment is to combine the movement and the static the right golden mean.

Duck Typing

Unfortunately, the delegate cannot overwrite all the features of the interface or class, and a friend mentions that "an interface is an abstraction of an object's functionality, and a delegate is an abstraction of a method's functionality." Then we naturally think, is there a way to apply the idea of a delegate to an object? Yes! It is: duck typing. As already mentioned, duck typing is concerned with "what objects can Do" or "How to use Objects", what class the object inherits from, or what interface is not important to implement. Duck typing was meant to be "if an animal, walking like a duck, barks like a duck, I can think of it as a duck." In contrast to the inherited polymorphism, duck typing can implement a non-inherited polymorphic state. By duck Typing, the more pure duck typing should look like this:

static void Main (string[] args

{

Object person= new Person ();

IPerson duck= duck.create<iperson> (person);//Create a Duck object


Console.WriteLine (duck. Name + "would be" + (duck). Age + 1) + "next year");

Duck. Play ("basketball");

Console.WriteLine (duck. Mother);/is a null

//duck cannot invoke duck. Sing ()


}

Interface IPerson
{
string Name {get;}
int Age {get;}
string Mother {get;}
void Play (string ball);
}

class person
{
public string Name {get {return ' Todd ';}}
public int Age {get {26;}}

public void Play (String ball) {Console.WriteLine (' Play ' + Ball);}

public void Sing (String song) {Console.WriteLine ("Sing + song");}

}

In the example above, although the person object does not implement the IPerson interface, we can create the properties and methods of the Duck object call person by duck.create<iperson> (person). The way in which interfaces and objects are bonded is very close to the way the delegates and the methods are bonded, and it really achieves what we call the idea of applying the entrusted idea to the object.

To implement the Duck.create<t> function in C #, you can dynamically create a proxy class that implements the T interface, block the method call in the proxy class, and convert the method call to a reflection call on the target object emit. Castle Open Source Project Dynamicproxy is a very useful tool, with its help it is easy to implement proxy class creation and method call interception.