Object-Oriented Software Design Principles (II)-corruption of Software Design

How do we know the advantages and disadvantages of software design? Below are some symptoms of poor design. when any of the following smells of the software, it indicates that the software is corrupt.

• Rigidity: it is difficult to make changes to the system, because each change forces many other changes to the other part of the system.
• Fragility: changes to the system may cause problems in many conceptual aspects of the system and the changes.
• Immobility: It is difficult to solve the tangle of the system and make it a component that can be reused in other systems.
• Viscosity: it is more difficult to do the right thing than to do the wrong thing.
• Unnecessary complexity (needless complexity): The design contains an infrastructure that has no immediate benefits.
• Unnecessary repetition: The design contains a duplicate structure, which can be unified using a single abstraction.
• Opacity: Hard to read and understand. The intent is not shown very well.

Rigidity

Rigidity refers to the difficulty in making changes to the software, even simple changes. If a single change leads to chained changes in dependency modules, the design is rigid. The more modules that must be modified, the more rigid the design.

Most developers encounter this situation: they make a seemingly simple change to the requirement. When he actually makes the change, it is found that the impact of many changes has not been predicted. Finally, the change takes much longer than the initial estimation. He would repeat what software developers often say: "It is much more complicated than I thought !"

Vulnerability

Vulnerability refers to the vulnerability that,ProgramProblems may occur in many places. It is often said that there is no conceptual correlation between the location where new problems occur and the location where changes occur. Fixing these problems will lead to new problems, making the software development team look like a dog that keeps chasing its own tail.

Robustness

Robustness refers to the design that includes useful parts for other systems, but the effort and risk required to separate these parts from the system are enormous. This is a pity, but it is very common.

Viscosity

When faced with a change, developers often find that there are multiple change methods. Some of them will maintain the design, while others will damage the design (that is, the blunt method ). When those methods that can maintain system design are more difficult to apply than those with blunt techniques, it indicates that the design is highly viscous. It is easy to do wrong things, but it is difficult to do the right things. In this way, it is difficult to maintain the software design in the project.

Unnecessary complexity

If the design contains components that are currently useless, it contains unnecessary complexity. When developers predict demand changes and place potential changes in the softwareCodeThis is often the case. At first, this looks like a good thing. After all, preparing for future changes will maintain code flexibility and avoid further painful changes.

Worse, the results are often the opposite. Preparing for too many possibilities makes the design contain structures that will never be used and thus become chaotic. Some preparation may bring about a return, but more will not. During this period, the design carries these unused parts, making the software complex and hard to understand.

Unnecessary repetition

Copy and paste may be useful text-editing operations, but they are catastrophic code-editing operations. Often, software systems are built on a large number of repeated code snippets.

When there is duplicate code in the system, it is difficult to modify the system. Errors found in a repeated code body must be fixed one by one in each repeated body. However, since there are minor differences between each duplicate, the correction method is not always the same.

Obscure

Obscure means that the Code module is hard to understand. When developers first write a module, the Code may seem clear to them. This is because they have made themselves focus on code writing and they are very familiar with the code. After their knowledge declines, they may look back at the module and wonder why they have compiled such bad code. To prevent this, developers must stand in the position of code readers and work together to refactor their code.

1. What inspires software corruption

What inspires software corruption? The answer is a change in demand. The design degrades as the requirements are not changed in the way foreseen by the initial design. Usually, the changes are urgent, and the developers who make the changes are not familiar with the original design ideas. Therefore, although the design changes can work, they violate the original design in some way. As changes continue, these violations continue to accumulate, and the design begins to smell bad.

However, we cannot blame demand changes for design degradation. As developers, we have a good understanding of demand changes. In fact, most of us recognize that demand is the most unstable factor in the project. If our design fails due to continuous and massive changes in demand, it indicates that our design and practices are flawed. We must try to find a way to make the design flexible for changes and apply some practices to prevent design corruption.

 

2 Examples of design corruption

Task assigned by the boss ......

The boss came to you early in the morning and asked you to complete such a program within three weeks: read characters from the keyboard and output them to the printer.

You are a very efficient developer. It takes only two weeks to complete the program (copy V1 ):

VoidCopy ()
{
Int C;

While (C = rdkbd ())! = EOF)
Wrtprt (C );
}
 

 

After you compile the program, install it on the company's 234 workstations. Your program runs well and has no problems in the past three months. So my colleagues praised you and the boss began to appreciate you. You started to float yourself.

 

Demand is changing ......

One morning after three months, the boss came to you and said that he sometimes wanted to read information from the tape. You gritted your teeth and turned your eyes white. You want to know why people always change their needs. Your program is not designed for the tape reader! You warn the boss that such a change will undermine the elegance of the program. But the boss glared at you and immediately lowered your head and began to think about a solution.

Because the program has been installed on hundreds of workstations, you cannot change the interface of the Copy Program. Changing the interface will result in a long time of re-compilation and re-testing. System Testing engineers will hate you alone, not to mention the seven guys Who configured the control group. In addition, the Process Control Department will use a dedicated day to review various code for all modules that call copy. However, this is hard for you. You cleverly completed the task (copy V2 ):

//Remember to reset this flag
BoolPtflag =False;
VoidVoidCopy ()
{
Int C;

While (C = (ptflag? Rdpt (): rdkbd ()))! = EOF)
Wrtprt (C );
}
 

 

The caller who wants the copy program to read information from the tape reader must set ptflag to true and then call copy to read the information from the tape reader correctly. Once the copy call returns, the caller must reset the ptflag. Otherwise, the caller will mistakenly read information from the tape rather than the keyboard. To remind programmers to reset this flag, you have added an appropriate comment.

Similarly, once your program is released, it will be well received. Even more successful than before, a large group of eager programmers are waiting for the opportunity to use it. Life is beautiful.

 

An inch in size ......

Good days always go too fast. A few weeks later, the boss came to patronize you that morning. He said: customers sometimes want the copy program to output to the tape piercing machine.

Customer! They always destroy your design. Writing software is much easier without customers.

Once again, you warn your boss that if you continue to change your demand at such a terrible rate, the software will become hard to maintain by the end of the year. The boss nodded and told you to make the change in any case.

This change is similar to the previous one, but requires another global variable. The following program shows the excellent results (copy V3) after your efforts ):

 

 
//Remember to reset these flags
Bool ptflag =False;
Bool punchflag =False;

Void copy ()
{
Int C;

While (C = (ptflag? Rdpt (): rdkbd ()))! = EOF ))
Punchflag? Wrtpunch (c): wrtprc (C );
}
 

 

Especially proud of you, you still remember to modify comments. Although, you are worried that the structure of the program is starting to become loose. Any change to the input or output device will force you to re-organize the condition judgment of the while loop. But after all, your program can work normally. But now you have reached the bottom line. If a hateful customer breaks your design by changing the demand, you will leave immediately. You made up your mind.

 

Your crash ......

Unfortunately, it didn't take two weeks. You didn't sit down in the office that morning, and the boss ran in again. Looking at his anxious look, you guessed that he had waited for you for three hours. The boss said, "The client sometimes wants the copy program to input ......

Before he finishes speaking, you have rushed out of the office and disappeared into the morning.

 

2.1 use object-oriented design principles to design the Copy Program

Let's change the scenario to deal with the above situation ?~ Pai_^ ~

1. When the boss gives you a task for the first time, you have not expected any changes in requirements, so the code written at the beginning is exactly the same as that of "Copy V1.

2. When the boss asked you to allow the program to read information from the tape reader, you responded as follows:

ClassReader
{
Public:
VirtualIntRead () =0;
};

ClassKeybordreader:PublicReader
{
Public:
Virtual IntRead (){ReturnRdkbd ();}
}

Keybordreader gdefaultreader;

Void copy (Reader & reader = gdefaultreader)
{
Int C;

While (C = reader. Read ())! = EOF)
Wrtprt (C );
}
 

 

3. When the boss asks you to make the program output to the tape piercing machine, you have made the following response:

 Class Reader
{
 Public :
Virtual   Int Read () = 0 ;
};

 Class Keybordreader: Public Reader
{
Public:

 Virtual   Int Read (){ Return Rdkbd ();}
}

 Class Writer
{
Public :
 Virtual   Void Writ ( Int C) = 0 ;
};

 Class Printerwriter: Public Writer
{
 Public :
 Virtual   Void Write ( Int C) {wrtprc (c );}
}

Keybordreader gdefaultreader;

Printerwriter gdefaultwriter;

Void copy (Reader & reader = gdefaultreader, writer & writer)
{
Int C;

While (C = reader. Read ())! = EOF)
Writer. Write (C );
}

 

To meet new requirements, you seize this opportunity to improve the design so that the design will be flexible for future similar changes, rather than trying to patch the design. From the first improvement, whenever the boss asks for a new input device, you can respond in a way that does not result in degradation of the Copy Program; from the second improvement, whenever the boss asks for a new input or output device, you can respond in a way that does not result in degradation of the Copy Program.

But please note that you did not try to predict how the program will change as soon as you design the module. Instead, you write it in the simplest way. You do not modify the design of a module until the requirement changes, so that the module remains flexible.

 

Note: Your program complies with the open-closed principle (OCP) and dependency inversion principle (DIP) in object-oriented programming ). [See the following section]

 

3 design corruption and design principles

Design corruption is a symptom that can be measured subjectively (if not objectively. Corruption is often caused by the violation of one or more of the design principles. For example, rigidity is often caused by insufficient attention to the open-closed principle (OCP.

The development team should use the appropriate design principles to eliminate corruption. However, these principles should not be applied when software is not corrupted. It is wrong to follow the principle unconditionally. These are not perfume that can be sprayed everywhere in the system. Excessive adherence to these principles will lead to the design smell of unnecessary complexity (needless complexity) and become another form of corruption.

 

Next chapter: Object-oriented software design principles (iii) -- software entity Design Principles

Codeproject