- 什么是原则
原则是一种规则、信仰或者指引你的观念，原则通常与价值观或价值体系直接联系。 - 保持简单直接原则（KISs）
KISS是（Keep is simple, stupid或 Keep it simple and stupid）
任何事情都应该尽可能简单，而不是稍微简单一点
–Albert Einstein, theoretical physicist, 1879-1955
对程序员来说，关注简单性可能是最困难的事情之一，并且这是一个终生的学习经验。
–Adrian Bolboaca(@adibolb),April 3, 2014, on Twitter - 不需要原则（YAGNI）
总是在你真正需要的时候再实现它们，而不是在你只是遇见到你需要它们的时候实现它们。
– Ron Jeffries, You’re NOT gonna need it !
它的主旨是希望你不要写目前用不上，但将来也许需要的代码。 - 避免复制原则（DRY）
复制和粘贴是一个设计错误。
– David L.Parnas - 信息隐藏原则
该原则指出，一段代码调用了另外一段代码，那么，调用者不应该知道被调用者的内部实现。否则，调用者就有可能通过修改被调用者的内部实现而完成某个功能，而不是强制性地要求调用者修改自己的代码。
信息隐藏的优点：
1). 限制了模块变更的范围
2). 如果需要修复缺陷，对其他模块的影响最小。
3). 显著提高了模块的可复用性。
4). 模块具有更好的可测试性。 - 高内聚原则
软件开发中的一条通用建议是，任何软件实体（如模块、组件、单元、类、函数等）应该具有很高的（或强的）内聚性。一般来讲，当模块实现定义确切的功能时，应该具有高内聚的特性。 - 松耦合原则
考虑下面的示例代码：
class Lamp {
public:
void on(){
//...
}
void off(){
//..
}
};
class Switch {
private:
Lamp& lamp;
bool state{false};
public :
Switch(Lamp &lamp):lamp(lamp){}
void toggle() {
if (state) {
state = false;
lamp.off();
} else {
state = true;
lamp.on();
}
}
};
这个设计有什么问题？
问题就是，我们的Switch类直接包含了一个具体类Lamp的应用。换句话说，这个Switch类知道那是一个具体的Lamp类。
在软件开发中，松耦合的关键是接口。接口声明类的公共行为，而不涉及该类的具体实现。接口就像合同，而实现接口的类负责履行契约，也就是说，这些实现接口的类必须为接口的方法签名提供具体的实现。
在C++中，使用抽象类实现接口，如下所示：
class Switchable{
public:
virtual void on() = 0;
virtual void off() = 0;
};
这个Switch类不在包含Lamp类的引用。相反，它持有了我们新定义的Switchable接口类。
class Switch{
private:
Switchable& switchable;
bool state{false};
public:
Switch(Switchable& switchable): switchable(switchable){}
void toggle() {
if ( state) {
state = false;
switchable.off();
} else {
state = true;
switchable.on();
}
}
};
这个Lamp类实现了我们新定义的Switchable接口。
class Lamp : public Switchable{
public:
void on(0 override{
//...
}
void off() override{
//...
}
};
松耦合可以为系统的各个独立的模块提供高度的自治性，该原理可以适用于很多不同层次：可以用在最小的模块上，当然，还可以用在大型组件的体系结构上。高内聚会促进松耦合，因为具有明确定义责任的模块，通常会依赖于较少的其他模块。
- 小心优化原则
不成熟的优化是编程中所有问题（或至少是大部分问题）的根源。
–Donald E. Knuth,American computer scientist[Knuth74]
建议：只要没有明确的性能要求，就避免优化。
note： profiler是一种动态程序分析工具。除其他常用指标外，它还测量函数调用的频率和持续时间，它收集的分析信息还可用于程序优化。 - 最少惊讶原则（PLA）
最少惊讶原则（POLA、PLA），也称为最少惊喜原则（POLS），它在用户界面设计和人因工程设计中很知名。该原则指出不应该让用户对用户界面的意外响应而感到惊讶，也不应该对出现或消失的控件、混乱的错误信息、公认的按键序列的异常响应或其他意外行为而感到困惑。
这个原则也可以很好地应用到软件开发中的API设计中。调用函数不应该让调用者感知到异常行为或一些隐藏的副作用，函数应该完全按照函数名称所暗示的意义执行。 - 童子军原则
这个原则是关于你和你的行为的，其内容是：在离开露营地的时候，应让露营地比你来之前还要干净。
童子军非常有原则，其中一个原则是，一旦他们发现了一写不好的东西，就立即清理环境中的污染物或那些引起混乱的东西。作为一名负责任的软件工程师，我们应该将这一原则应用于我们的日常工作，每当我们在一段代码中发现需要改进的或者风格不好的代码时，我们应该立即修正它，与这段代码的原创是谁无关紧要。