Replaying old things -- talking about interfaces and abstract classes

1. Start with dependency inversion

First, let's take a look at the dependency inversion in Agile Software Development:

A. High-level modules should not depend on low-level modules. Both of them should depend on abstraction.

B. abstraction should not depend on details, but on abstraction.

Let's leave the second point to look at the first point, what is a high-level module and what is a low-level module. In my understanding, the high-level module is the strategic module and the business module. The lower-layer modules are tactical modules and detail modules.

Let's take a look at this section.Code:

     Class Person { Private Mouth mouth; Public Person (mouth ){ This . Mouth = mouth ;} /// <Summary>          /// Meal          /// </Summary>         Public   Void Eat (){ If (Mouth = Null ){ Throw   New Nullreferenceexception ();} mouth. openmouth (); fillmouthwithfood (); mouth. closemouth ();} Private   Void Fillmouthwithfood (){}} Class Mouth { /// <Summary>          /// Mouth opening         /// </Summary>          Public   Void Openmouth (){} /// <Summary>          /// Shut up          /// </Summary>          Public   Void Closemouth (){}}

 

Some may say that this is a normal code. However, we must consider that the Opening and Closing actions are specific actions, and the specific actions may change. Here, the person class of the high-level Code also depends on the lower-level code. When the lower-level code changes, the higher-level code changes accordingly. As the number of layers increases, the intensity of the shock increases.

Next let's look at a figure like this:

In traditional process design, reuse tends to be performed on low-level modules. For exampleAlgorithmThe reuse of data structures, the reuse of some general functions, the reuse of details, and the reuse at the tactical level. This is the disadvantage that the top layer depends on the bottom layer. (Please note, I did not say that this is not good .)

How can we solve this problem.

2. abstraction. Let's talk about abstraction.

This word is too fashionable. Of course, it is also very abstract, so what is abstract.

Let's take a look at the interpretation of the word in the modern Chinese Dictionary: abstraction is formed by dropping individual, non-essential attributes from many things and extracting common features.

Abstract classes and interfaces are abstract. Therefore, many books say that interfaces are better than abstract classes. I think this sentence is really a very bullshit! The interface is abstract. Isn't the abstract class abstract? There are two completely different things. How can we compare them ?!

During the interview, you may have been interviewed about the difference between interfaces and abstract classes. The most common answer on the internet is that interfaces represent a can-do syntax, an abstract class is the semantics of is-. This sentence is not without reason. I used to answer both the test and interview questions. But now I don't think this sentence can be of any help to the real design.

To put it this way, any method can be expressed as the can-do semantics. That is not to say that all methods must be put into the interface, and all abstract classes are anemia classes, or do all abstract classes need to implement interfaces?

3. Differences between interfaces and abstract classes

Looking back at the dependency inversion principle we mentioned in the first point, the high-level should not rely on the lower layer, so that the design should not follow the design from the lower layer to the higher layer. Instead, we should first design the overall business (that is, the high-level module, strategic content), and then design the lower-level module (that is, the specific implementation) based on the high-level module ). Instead of directly generating dependencies between the top and bottom layers, an abstraction layer should be built between the two layers. In my opinion, this abstraction layer can be called an interface ".

Here I will introduce my understanding of interfaces and abstract classes: interfaces come from high-level requirements, and abstract classes come from the bottom layer.

Let me explain this sentence. When designing a high-level module, this high-level module does not know the details of the lower-level module, or even the implementation method. It only knows that I need this behavior, and then I need this behavior. For example, this Code:

ClassGame {Public VoidSport () {run (); walk (); swim ();}}
 

This is a high-level code. One sport in the competition is running first, competing, and finally swimming. The competition may be divided into men's and women's groups. Different people walk and run differently. But I don't care who this behavior belongs to. I only want to know that I need this behavior. This is the source of the interface.

     Class Game { Private Irunable runner; Private Iwalkable Walker; Private Iswimable timer mer; Public Game (irunable runner, icyclable Walker, iswimable timer mer ){ This . Runner = runner; This . Walker = Walker; This . Timer mer = timer mer ;} Public   Void Sport () {runner. Run (); Walker. Walk (); timer Mer. Swim ();}} Interface Irunable { Void Run ();} Interface Iretriable { Void Walk ();} Interface Iswimable { Void Swim ();}

However, abstract classes are extracted from the underlying implementation. So we can also say it another way.

"An interface is an inevitable result of object-oriented analysis and design, while an abstract class is the result of reconstruction ".

Or we can say:

"First interface, then abstract class ".

I would like to end this section, but I want you to further understand my point of view,The interface should never be extracted from the two classes..

4. Bottom-up vs top-down

Which of the two is better? I believe everyone has their own opinions. Let's take a look at the advantages and disadvantages of the two methods.

The key to the bottom-up method lies in assembly. The lower layer is designed first, and the lower layer does not know the business of the higher layer, just like building blocks. Every building block is not designed for the final building, it follows its own shape. The key lies in the player's own assembly.

The key to the top-down method is the initial business analysis. Based on the business in the requirement document, the business model is extracted and the behavior of each business is analyzed based on the business model, then implement each behavior separately.

The biggest advantage of the bottom-up method is the reusability of the underlying modules. Like a building block, it can be built into a tall building or a dog house. However, the disadvantage is that the underlying changes will cause high-level cascade shocks. In addition, building block designers are equivalent to our architects, and players are equivalent to our "set pages"ProgramThe quality of the architect will directly affect the success or failure of the final project.

The biggest advantage of the top-down method is that the dependency inversion ensures the reusability of the business. In addition, architects are not allowed to imagine a business logic out of thin air, instead, the entire business model is implemented based on the business logic in the requirement document. Of course, the disadvantage is that the reusability of the underlying code is extremely low.

So how should we do it. Here I only propose my own point of view.

There is a "v" font model in software engineering. I cannot remember what it is. Here, I think we can also use the vword model.

When receiving the requirement document, use the top-down analysis method to sort out the relevant business, and then roughly implement the logic of each business. Based on these Implementation logic, extract the interface and OK. The high-level module has been designed.

Next, we will use the bottom-down method for analysis. In fact, this is what we often call the "Domain Model". Believe me, it is difficult to design a general domain model simply by using the top-down analysis method. This domain model is our most reusable module. The design of the domain model is also the biggest application of our "design model.

The above two sections are typical abstract classes after interfaces.

At the end of the article, the more chaotic it is, forget it, stop it ......