What is dependency and what is Abstraction

What is dependency and what is abstraction 1. About dependency and coupling: from a small country to a harmonious society

In Lao Tzu's "little country and few people" theory, I proposed an ideal social state: neighboring countries look at each other, and the people are dead and busy. This is a kind of social ideal of the old man's family. The old and dead people present a harmonious scene. Because there is no correlation, it does not matter, and thus cannot lead to conflicts. This is the ultimate philosophy in the philosophy of the ancestor, but the ideal Datong always has a more or less gap with the real ecology, and human society cannot avoid the occurrence of connections. Therefore, the ideal of little country and few people has become a beautiful dream, cannot be implemented. Similarly, ing to the software "Society", that is, the software system structure, also indicates that there must be more or less connections between different levels, modules, and types, this kind of contact is inevitable but manageable. Just as although human society cannot achieve small countries and few people, in an ideal situation, we advocate a harmonious society, and change the contact between people from complexity to simplicity from twists and turns to unification. This association can also be very harmonious. Therefore, the Mission of the software system should also move forward towards the goal of a harmonious society. To deal with different relationships, we should use a set of effective philosophy to simplify complicated problems and make rigid problems flexible, in my opinion, this philosophy or method is the dependent philosophy, that is, the central idea to be explained in this article.

Because coupling is inevitable, the philosophical idea of dependency is explained step by step from understanding the concept of dependency and coupling.

(1) What is dependency and coupling?

Dependency refers to the relationship between software entities. Software entities may be modules, layers, or specific types. Different entities directly depend on each other, which means coupling occurs. Therefore, dependency and coupling are two expressions of a problem in my opinion. Dependency explains the nature of coupling, while coupling quantifies the degree of dependency. Therefore, the description of the relationship can be analyzed from two perspectives.

From the perspective of dependency, it can be classified:

· No dependency indicates that there is no link between the two. Therefore, they are independent from each other and have no coupling relationship.

· One-Way dependency: The dependency between the two parties is one-way, indicating that the direction of the impact is also one-way. If one entity changes, it will affect another entity. Otherwise, low coupling.

· Two-way dependency: The dependency between the two parties is mutual, the impact is also mutual, and the coupling degree is high.

From the perspective of coupling, it can be classified as (Here we return to the specific code-level coupling concept to facilitate the interpretation of the concept ):

· Zero coupling, indicating that two classes are not dependent.

· Specific coupling: If a class holds a reference to another specific class, the two classes have a specific coupling relationship. Therefore, the specific coupling occurs between specific classes, so changes to specific classes will affect their associated classes.

· Abstract coupling occurs in the dependency between a specific class and an abstract class. Its biggest function is to implement flexible scalability and stability by applying object-oriented polymorphism mechanisms to abstract dependencies.

Different coupling represents the difference in the degree of dependency. The degree of coupling is analyzed based on the concept of "granularity. Separating coupling by referencing the middle layer can make the design more elegant and the architecture more flexible, but direct dependency also exists in its market. Excessive design is not desirable. Because efficiency and performance are also factors that need to be considered in the design. Excessive unnecessary separation will increase the number of calls, resulting in a waste of efficiency.

One of the drawbacks of the dependency inversion principle is further elaborated on this issue.

(2) how coupling is produced

So how is the coupling between software entities produced? Returning to the code snippet that is sprinkling every day is actually repeatedly creating coupling and benefiting from the data communication brought about by this coupling. If we look back to the beginning of software design, we can use a simple machine language to implement the simplest logic, give an input, and implement an output, which can be expressed as 3-1.

With the revolution in the software world and the complexity of business logic, the simplification of the above processing is no longer enough to implement more complex software products. When the complexity inside the system exceeds the level that the human brain can recognize, we need to sort it out in a more scientific way, as shown in 3-2.

As a result, humans began to take advantage of restructuring and simplification, and developers had to strike a balance in software design. The result of the balance is to modularize the complex system and simply handle complicated problems, so as to be recognized by the human brain. Based on this guiding principle, with the increase of complexity, the division of modules is more refined, especially the emergence of object-oriented programming theory, which makes the complex processing a more scientific theoretical basis. However, complicated problems can be implemented by dividing simple functional modules or technical units, but as a result, more and more sub-units will emerge, in addition, more and more sub-units must communicate with each other to complete unified business processing. As a result, more and more data communication management is generated. For the management of sub-units, that is, the core concept of this article-dependency, to become a new software design issue, so we can sum up the experience of our predecessors and extract the wisdom of our current people, the coupling generation is summarized as follows:

· Inheritance

· Aggregation

· Interface

· Method call and reference

· Service call

After understanding the general method of coupling, we can discuss the core idea, that is, on the basis of understanding and understanding dependencies, the ultimate goal.

Statement

Design goals: High Cohesion and low coupling ).

After a long discussion, it was finally time to make a summary of dependencies and coupling, and it was time to make some target demands. In the field of software design, there are several high principles worth remembering by every developer. They are:

· Abstract Programming

· Low coupling and High Cohesion

· Encapsulation changes

· Implementation reuse: code reuse and algorithm Reuse

By the way, these ordinary words bring together the core content of Object-oriented thinking and are also the meditation sutra that this article strives to explain. Abstract programming and encapsulation changes will be explained in detail later. Here we need to focus on the goal of "low coupling, high cohesion.

Low CouplingWhich represents the simplest dependency, minimizing the relationships between classes and classes, modules and modules, layers and layers, and between systems. Low coupling reflects the ideal state of human pursuit of simple operations. The simplification of the relationship between software entities is pursued based on the basic implementation skills of software development, which is the goal of most design models; low coupling reduces the impact of a class or module modification on other classes or modules and simplifies the impact scope. In the dependency mode described in this article, one-way dependency and abstract coupling are all basic conditions for low coupling.

High CohesionOn the one hand, it represents the unified management of duties, and on the other hand it reflects the effective isolation of relationships. For example, a single responsibility principle is actually a guiding embodiment of functionality. It encapsulates closely related responsibilities into a class (or module ), the judgment criterion is based on the cause of class changes. Therefore, encapsulation is inseparable from dependencies, while abstraction is inseparable from changes. Both concepts and essence are relative. Therefore, the goal of High Cohesion reflects the idea of unified management with isolation as the goal.

Therefore, in order to achieve the goal of low coupling and high cohesion, the design principles and design patterns in the general sense are actually implemented in this direction. Therefore, simply summarizing is not a general rule:

· Implement individual dependencies as much as possible.

· Do not associate the two sides that do not need to exchange data. People refer to this image as "don't talk to strangers (don't talk to strangers )".

· Maintain internal encapsulation. The two parties involved should not communicate with each other in depth, which is an essential condition for ensuring high cohesion.

 

This article is excerpted from the book ". Net (version 2nd) You must know ".

Book details: http://blog.csdn.net/broadview2006/article/details/6673353