基本情况
DRY，Don’t repeat yourself，就是不要重复你自己的意思。
不要重复，是多么简单的意思了，重复就是多了一个一样的东西，为什么多一个呢，一个就可以了，这样才简单，这是一个常识。
光说常识不行，得把常识变成你的意识，让你意识得这样做，融到编码当中去。
重复的代码，这是程序当中最容易出现的情况了，并不是说，都不允许重复，比如两个不同的知识，但是同样的代码，这是应该的。
如果一过程重复了十几遍，你修改的时候，就得修改十几处，这一个原则，对程序员大大的友好啊，一定要记住这个原则，
程序员修炼之道中这样说：
作为程序员，我们做的就是收集、组织、维护以及治理知识。我们
把知识文档化，写进规范；通过运行代码赋予知识以活力；在测试过程
中，运用知识去知道应提供哪些检查。
不幸的是，知识并不稳定。知识会改变——通常频率还很高。可能
只要和客户开个会，对需求的理解马上就变了。政府改了条规定，一些
业务逻辑就过时了。也可能是测试提示之前选的算法行不通。所有这些
不稳定因素意味着，在维护模式下，重新组织和表达知识将会花掉大部
分的时间。
大多数人认为维护始于程序发布，这里的维护指修复Bug和增强特
性。我们觉得这些人搞错了。程序员一直处于维护模式下，从未间断。
我们的理解每天都在变化。当我们在项目中埋头工作时，新的需求会不
断出现，已有的需求也会发展。也可能是环境发生了变化。不管具体原
因是什么，维护从来不是个离散的活动，而是整个开发过程中的常态。
当我们进行维护时，必须找到并变更事物的表达——那些嵌入程序
的知识胶囊。问题是，在规范、流程、开发的程序中复制知识太容易
了，一旦我们动手这么做，就会招致维护的噩梦——这个噩梦在程序发
布前就会开始。
我们认为，想可靠地开发软件，或让开发项目更容易理解和维护，
唯一的方法是遵循下面这条被称为 DRY 的原则：
在一个系统中，每一处知识都必须单一、明确、权威地表达。
说的再多，不如举例，下面以实例说明：
比如如下的C++代码：
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";}
}
为了更明白代码，加上头文件：
#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;
};
运行情况：
上面有重复的就是判断成绩是否合格，语文，数学这方面的判断逻辑一样的，根据不要重复自己的原则，因此，可以更改如下：
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();
运行情况：
总结
DRY原则，就是不要重复自己，要求：在一个系统中，每一处知识都必须单一、明确、权威地表达。
这一点不仅在代码过程当中，在数据结构，甚至文档当中都需要遵守这一原则。
比如：这一个数据结构：
typedef struct _Exam
{int beginTimeSec;int endTimeSec;int duration;
}EXAM;
有了开始，结束时间，就不需要时长了。
最后，以一张图来说明：
