Open eye, epiphany Software Design

Open eye, epiphany Software Design

[It168]The night is quiet, and the surrounding area is quiet, and the Earth is turned into silver. At this time, the stars in the sky are like countless stars
The Treasure of the dark night sky dotted with a few flashes. With this, the software development department on the third floor of Yijing company is brightly lit. The sky is speechless, and the stars and months are affectionate. I don't know how long it will take, and the sky in the East begins to grow.
It's almost the last day. Tension rubs red eyes, and then continues to work overtime to modify the software program that was returned to the project supervisor yesterday. Tension is a software development programmer who developed software projects yesterday.
At the review meeting, his program was evaluated by project manager Simon as completely non-conforming to the OO design model and design path. Four serious signs of decay in software design are too stiff, too fragile, and unrecoverable.
The usability and viscosity are too high.

Tension looked at the white sky outside the window and remembered the comments of project manager Simon: first, the program is too stiff, making it difficult to change the software. Every change will cause
The consequence of a series of changes to mutually dependent modules is that no one dares to make changes, because he never knows when a change will be completed. Second, being too fragile will make the system output in many places when software changes
Errors often occur in a module that is not directly related to the change. Such software cannot be maintained, and every maintenance makes the software more difficult to maintain. There is also the reusability
So that it cannot be reused in other projects or other locations of the project. With a sigh of relief, is his software design really like what Simon's manager said before leaving work that he has not yet begun to understand the path of software design?

1. What is software design?

Finally, at work, tension quickly washed his face and walked to the Project Supervisor's office of Simon manager, asking him what is kaitian and wudao. Simon looked at the night without sleeping, and his eyes turned red and said, "What?
Yes? Tao is people's understanding of some of the most basic rules and rules of the world. Wudao has five eyes and six links, which are headed by Tianyan. People have heard of the word "Tao" more or less, but do not know the key.
What is it? Simply put, the simpler the truth is, the closer it is to its essence. The enlightened person is able to look at the environment in front of him and look at the stars. People with high understanding stand taller, see farther, think deeper, and do closer
Nature. Understanding is the heart of consciousness. We call a thorough wisdom "Understanding ". It can be called "penetrating and surpassing the appearance of things to directly achieve the original purpose of things ".
"Epiphany"-it's just a flash of an eye.

"Software design also requires careful understanding to realize the" way "of software design ". The "path" of software design does not lie in how gorgeous and exquisite the design is, but in its simplicity and nature, and ultimately achieves "success with no tricks"
", Entering a new realm ". Simon paused for a moment and continued: "So, are there some basic principles in the software design process? We can discuss with our colleagues at today's software exchange meeting.
The most basic principle in software design ".

"The best practice of programming can be divided into two parts: foreign and internal work. Superior software design must be flexible, both internal and external, return to nature, and abide by the Basic Law ". Simon at Software
The design Exchange Conference concluded: "To Realize the software design, Let's first look at some of the" external "features of the system, including readability, high flexibility, scalability, versatility, and portability, these features can be summarized
"White box features of foreign customers ". The system should also have some "internal" attributes, such as high cohesion and low coupling. These internal attributes are more focused on internal structure and are summarized as "internal Black Box attributes ".

At the same time, Simon also mentioned that some measures and methods can be used to make a system design have these excellent features. These methods/means include abstraction (Improved versatility), encapsulation (enhanced cohesion), separation (reduced
Coupling. When these methods/methods are refined, classified, and summarized, some design principles/guidelines are generated, such as interface-Oriented Programming and preferential use of object combinations. These principles/principles must be
The classic expression in the scenario produces a design pattern.

 

2. Foreign white box approaches: readability and reusability
Software design is a white box, including readability, high flexibility, scalability, versatility, and portability. Here we will introduce two points in detail: readability and reusability.

In the life cycle of a software, 80% of the time and cost are spent on maintenance. We can see that almost no software is maintained by the original developers throughout its lifecycle. Whether from soft
From the perspective of modification, testing, or transplantation, the readability of the software must be mentioned in a very important position. The commonly used methods for improving the readability of software include coding standards, not just detailed annotations. Readable
Strong encoding specifications are especially important for programmers, allowing them to fully understand new code as soon as possible. On the other hand, a readable design is also very important for testing and checking bugs. Therefore, we recommend that you
Each software developer must comply with the coding specifications to improve the readability of the program.

To meet the needs of the software crisis, the highest level of software design principles is reusability and scalability. In many software solutions, the design principle is object-oriented. Then, when we target our needs
Is one object a good design? In fact, it is very difficult to grasp how to divide and design really good objects. In fact, we all know that the basic purpose of object-oriented development is code reuse. Reusability is
By reusing previous labor results, we can improve development efficiency and reduce costs. There are many things and layers around reusability, such as code-Level Reuse, design reuse, Component reuse, and framework reuse.

Software reuse not only improves the productivity of software, but also improves the maintainability of software. Previously, reuse mainly involved code, functions, and structures. Currently, reuse mainly targets classes and interfaces,
Components. However, Reuse does not necessarily guarantee Software maintainability. It cannot be reused because of code duplication or other reasons. It needs to be analyzed based on the specific situation. To enhance the maintainability of the system through reuse
Certificate reuse supports maintainability reuse.

The following basic design principles can be used to guide practice.
Open-closed principle (OCP): the principle of open-closed is the cornerstone of object-oriented reusability. It mainly refers to a software entity that is open to extensions and closed to modifications. When designing a module, the module should be extended without being modified. Systems that meet this principle are reusable at a higher level and easy to maintain.

So how can we meet the principle of opening and closing? Abstraction is the key. The abstraction layer and implementation layer must be separated. In a software system, the abstraction layer should be relatively stable, and the Implementation layer can be changed and expanded. We can
Many things and problems are abstracted and different levels and perspectives are abstracted. The open/closed principle is also the encapsulation principle of variability. It finds and encapsulates the variable factors of the system. Encapsulate a variability into
Object, then the different representations of this variability are the specific sub-classes of this class.

LSP: LSP is the cornerstone of inheritance reuse. It can be replaced by its subclass in any parent class. In fact, it is very important to design a class-level architecture.
. Another thing that needs to be emphasized is the Dependency inversion principle (DIP): that is to say, it depends on abstraction rather than concrete implementation. In traditional process systems, high-level modules depend on low-level models.
The abstract level depends on the specific level. As a result, any changes to the underlying layer will affect the upper layer. Such a software system has no maintainability. Abstract layers should not depend on specific implementation details so that
This ensures the reusability and maintainability of the system.

How can we apply this principle in practice? Programming for interfaces instead of implementations. So when the implementation changes, it will not affect other places. In Java, interfaces and abstract classes should be used for variables.
Type Declaration, parameter type declaration, method return value type, and so on. Coupling in an abstract way is the key to the dependency reversal principle. According to the dependency inversion principle, a large number of classes, such as abstract classes and
Interface, because it assumes that all the classes may change.

 

3. Inner's black box path: low coupling and high aggregation

If you use an exclusive arrow to link a designed object, it will often become a network. If you use an exclusive arrow to link methods of the object, it will look like graffiti. For designers
It is also difficult to clearly describe the relationships among them, and for developers, it becomes a black hole. When user requirements change, such a design will become a nightmare. Of course, this is an extreme situation.
However, it can also be noted that reducing coupling at all levels of design is the key.

Generally, most of the software contains multiple modules, and the modules are more or less coupled. The coupling of these functions is the most ideal state, that is, configurable and detachable. Any
The removal of modules does not affect other functions. In addition, more functions are configured. That is to say, each module can be replaced or removed just like a building block, but it cannot be affected.
Other functions. Software that can be configured and loaded will surely be a more ideal development model for future software. This is very good for system maintenance and adaptability to changes required.

Therefore, the design of "inner's black box" is: low coupling and high aggregation. The fundamental purpose of various software design principles, such as dependency inversion, single role principle, interface-oriented, and various design patterns, is to reduce coupling. Only low coupling can better adapt to changes, and better reuse and expansion.

In general, our common implementation methods are: using design patterns to encapsulate changes and reduce coupling. The design pattern is a tool used to "encapsulate changes and reduce coupling. It is the product of object-oriented design. Its essence is to make full use of the three characteristics of object-oriented, namely, encapsulation, inheritance and polymorphism, for flexible combination and application.

Of course, coupling is inevitable in any case. When we implement interfaces and inherit the parent class, coupling is inevitable. However, coupling has different granularities. What we need to know very clearly is what decoupling requires.
Until the granularity. In general, the granularity of reuse of modules should prevail. Try to remove coupling between reuse modules or objects. Coupling within Reusable Modules should belong to the scope of aggregation, so do not blindly decouple them; otherwise
This is a misunderstanding.

Here, let's go back to the dashboard to see how to decouple it. There are two ideas: (1) Abstract specific things. (2) centralized processing of scattered things. Reduce coupling, that is, decoupling is the key. When we achieve low coupling and high cohesion, we also achieve another goal of software design, high scalability and high reuse.

 

Iv. Taste reconstruction and maintainability

Software maintainability is the regeneration of software. Therefore, another basic "path" of system design is maintainability. It mainly includes the following aspects: scalability, flexibility, and insertion ability. Scalability is a new feature.
It is easy to integrate into the existing system without affecting other modules of the system. Flexibility means that code modifications are allowed to take place smoothly. When one change is made, it will not affect the other, which can reduce the maintenance cost.
Insertability means that it is easy to replace an existing class with a class. If the interfaces are the same, changing the implementation class will not affect the users of the class.

Maintainability can extend the service life of the system and increase the value of software products. Therefore, in the software life cycle, maintainability becomes very important for products with large projects and versions that need to be constantly upgraded. Maintainability depends on scalability. scalability comes from adaptability to changes, rather than pre-judgment on changes.

When talking about the maintainability of software design, we have to propose refactoring. The importance of refactoring begins with the software life cycle. Generally, there is only one factor that threatens the Software Life: the change of demand. When software needs to adapt
When demand changes, there is a bad phenomenon: software products were originally carefully designed and well structured. However, with the development of time and demand changes, you must constantly modify the original functions,
New features are added, and some defects need to be modified. To achieve changes, it is inevitable to violate the original design architecture. After a while, the architecture of the software was broken. More and more bugs
More and more, more and more difficult to maintain, more and more difficult to achieve new requirements, software architecture for new needs gradually lose support capabilities, and become a constraint.

Refactoring can avoid this phenomenon to the maximum extent. It can reorganize the internal structure without changing the external functions of the system. Through restructuring, we constantly adjust the system structure so that the system can always adapt to changes in demand.

Conclusion
Compliance with the "path" of software design is a channel to achieve the goal of excellent software design. The design pattern is a manifestation of this goal. Simply put, highly reusable software must be highly scalable, and highly scalable software must have high cohesion and low coupling characteristics. Therefore, software complying with the design principles has a high cohesion and low coupling design feature, that is, maintenance, high scalability, and high reuse design.