C # static and dynamic combination programming bis: Two kinds of philosophy

In the previous installment of this series, we talked about comparisons between interface and delegate syntax constraints, and my conclusion is that the syntax constraints of interfaces are stronger than delegates. This topic got a lot of friends ' attention and discussion. In this respect, I have a brief summary of the relationship between the interface and the delegate on the basis of the comprehensive feedback, access to the data, and the understanding of myself, and promote the introduction of this article.

On the one hand, interfaces and delegates are two means of realizing polymorphism from the perspective of OO, on the other hand, from the point of view of software design, interfaces and delegates are two means of separating the specification from the implementation and facing abstract programming. Therefore, in the sense of existence, interfaces and delegates have important connections. Although the delegate does not cover all the functions of the interface, the comparison of the intensity of the grammatical constraints is not fully persuasive, but we can clearly appreciate that the delegate is more flexible than the interface.

Two kinds of philosophy

Of particular note here are the two philosophies represented by interfaces and delegates: Inheriting Philosophy and duck philosophy. Inheritance philosophy focuses on the structure of object inheritance, that is, "what you inherit is what you are"; the duck philosophy focuses on the nature of the object, which is "what you can do and what you are". PS: The name of "Duck philosophy" originates from duck typing. "If an animal walks up like a duck and barks like a duck, I can take it as a duck."

It should be emphasized that the philosophy of inheritance is not only embodied in the interface, but also the philosophy of ducks is not only embodied in the entrustment. And the two philosophies, each has its own advantages, there are applicable occasions, there is no competition, here only to see their differences, to flexible use.

Let's take a look at an example: The field modeling of sports, where we focus only on the modeling of coaches and players.

From inheritance to composition

According to the methodology of the inheritance philosophy "What should inherit what", it is easy to think of the definition Iplayer,icoach interface, let the member inherits (realizes) IPlayer, lets the coach inherit Icoach. In general, this would not have been a problem, but the situation might be different given the critical element of the object lifecycle. For example, we know that Liu Guoliang was originally a table tennis player, and later when the coach, to express Liu Guoliang from the players to the coach is not so easy to change. Because C # is a static type language, inheritance relationships are determined at compile time, inheritance relationships cannot be deleted at run time (Liu Guoliang retired), and inheritance relationships can not be increased at run time (Liu Guoliang coaches). It is also possible to think that the player Liu Guoliang and coach Liu Guoliang are two objects, but this necessarily affects whether the expression of the domain model is natural.

Many experienced friends may have realized that inheritance in C # is a very strong static constraint, and if the domain model is complex enough to behave in an object lifecycle, it must be used with caution.

Using a combination instead of inheritance is a common way to increase the flexibility of the model, generally by abstracting behavior into behavioral classes/interfaces/delegates, such as defining iplay,iteach behavior interfaces and adding behavioral attributes to objects play and teach. Although the combinatorial relationship cannot be dynamically added and deleted in C #, it can be compromised by, in the example above, the behavior attributes of play and teach must be present throughout the object's lifecycle, and there is no behavior to express objects by throwing Run-time exceptions.

To a certain extent, the transition from succession to composition shows the flexibility of duck philosophy. In fact, the so-called "behavior" is "what can be done." It is not difficult to find through the example above that the combinatorial relationship gives greater flexibility by shifting the focus from "inheriting what" to "what can be done." This transformation is not reluctantly, very natural, it is in line with the nature of the field. Although the composite relationship in C # is also static, but has more dynamic elements than inheritance, and dynamic and static itself is not good or bad, must be based on domain modeling needs to grasp the discretion.

Subsequent

Next, I will focus on the duck philosophy more pure embodiment: Duck Typing, please pay attention!