basic situation
DRY, Don't repeat yourself, just don't repeat yourself.
Don't repeat, it's so simple. Repetition means having one more of the same thing. Why do you have one more? One is enough. That's how simple it is. This is common sense.
Just talking about common sense is not enough, you have to turn common sense into your consciousness, let your consciousness do this, and integrate it into the code.
Duplicate code, this is the most likely situation in the program, not to say that duplication is not allowed, such as two different knowledge, but the same code, this should be.
If a process is repeated more than a dozen times, when you modify it, you have to modify more than a dozen places. This principle is very friendly to programmers. You must remember this principle. It is said in the way of programmers' cultivation
:
As programmers, what we do is collect, organize, maintain, and govern knowledge. We
document knowledge into specifications, animate knowledge by running code, and
use knowledge to know which checks should be provided during testing.
Unfortunately, knowledge is not stable. Knowledge changes—often with high frequency. Maybe
as long as a meeting with the customer is held, the understanding of the needs will change immediately. When the government changes regulations, some
business logic becomes obsolete. It may also be that the test prompts that the previously selected algorithm does not work. All these
instabilities mean that reorganizing and expressing knowledge will spend most of the time in maintenance mode
.
Most people think that maintenance starts with a program release, where maintenance refers to fixing bugs and enhancing features
. We think these people got it wrong. Programmers are in maintenance mode all the time, without interruption.
Our understanding changes every day. As we dig into projects, new requirements
emerge and existing ones develop. It could also be that the environment has changed. Whatever the specific reason
, maintenance is never a discrete activity, but rather a constant throughout the development process.
When we do maintenance, we have to find and change representations of things -- those
capsules of knowledge embedded in programs. The problem is that it's all too easy to replicate knowledge in the specifications, processes, and programs that are developed
, and once we do that, it invites a maintenance nightmare—a nightmare that
starts before the program is released.
We believe that the only way to develop software reliably, or to make development projects easier to understand and maintain,
is to follow this principle known as DRY:
In a system, every piece of knowledge must be single, unambiguous, and authoritative to express.
No matter how much to say, it is better to give an example. The following is an example:
For example, the following C++ code:
StudentScore::StudentScore()
{
m_scoreLanguage = {
"语文", 60};
m_scoreMath = {
"数学", 60};
}
void StudentScore::printScore()
{
if(m_scoreLanguage.score >= 60)
{
qDebug()<< "语文合格";
}
else
{
qDebug() << "语文需要补考";
}
if(m_scoreMath.score >= 60)
{
qDebug()<<"数学合格\n";
}
else
{
qDebug()<<"数学需要补考\n";
}
}
In order to understand the code more clearly, add the header file:
#ifndef STUDENTSCORE_H
#define STUDENTSCORE_H
#include <string>
#include <iostream>
using namespace std;
typedef struct _Score
{
string course;
int score;
}Score;
class StudentScore
{
public:
StudentScore();
void printScore();
private:
Score m_scoreLanguage;
Score m_scoreMath;
};
Operation status:
There are repetitions in the above to judge whether the grades are qualified or not. The logic of judgment in Chinese and mathematics is the same. According to the principle of not repeating yourself, it can be changed as follows:
string StudentScore::productResult(string course, int score)
{
string result;
if(score >= 60)
{
result = course + "成绩合格";
}
else
{
result = course + "需要补考";
}
return result;
}
void StudentScore::printScore()
{
qDebug()<<productResult(m_scoreLanguage.course, m_scoreLanguage.score).c_str();
qDebug()<<productResult(m_scoreMath.course, m_scoreMath.score).c_str();
Operation status:
Summarize
The DRY principle is not to repeat yourself. It requires that in a system, every piece of knowledge must be expressed in a single, clear, and authoritative manner.
This is not only in the code process, but also in the data structure, and even in the document. This principle needs to be followed.
For example: this data structure:
typedef struct _Exam
{
int beginTimeSec;
int endTimeSec;
int duration;
}EXAM;
With start and end time, there is no need for duration.
Finally, a picture to illustrate:
