在design pattern时通常我们会遵循一些原则，其中SRP原则在设计单一类时比较常见，它建议我们将类的粒度打散，尽量将一个类设计成只完成一种工作，也就是在类中尽量少的封装对外接口，在完美情况下，引起类变化的原因只能有一个
比如，我们设计一个code generator, 首先考虑类可以封装哪些函数，需要哪些数据， 一个代码生成器需要将代码写到文件中，于是我们需要这些函数: 打开文件，写入文件，保存文件， 而数据方面，我们只需要一个string，用来将它写入文件中
代码只是演示，并没有真正实现这些操作
class CodeGenerator
{
public:
void open_file() {cout<<"Open a file"<<endl;}
void write_file()
{
cout <<"Write the string into the file: ";
cout <<mystring<<endl;
}
void save_file() {cout<<"Save the file"<<endl;}
private:
string mystring;
};
相信大家觉得这样设计类是没有问题的， 但是随着这个类的职责发生变化(减少，增加，修改)， 类中的成员函数也会发生变化，而引起这些变化的原因有很多，比如， 我写入文件的方式换成以二进制的形式完成，我打开文件的方式以追加的方式完成，又或者我需要读取文件的内容，这些需求都会
引起类的改变，虽说上面的例子比较简单，函数之间没有相互的影响，但如果在实际运用中可能会非常复杂，经常的修改代码会导致维护困难。。。。。
OK, 提供解决方案 :
class OpenCodeGenerator
{
public:
void open_file() {cout<<"Open a file"<<endl;}
};
class WriteCodeGenerator
{
public:
void write_file()
{
cout <<"Write the string into the file: ";
cout <<mystring<<endl;
}
private:
string mystring;
}
class SaveCodeGenerator
{
public:
void save_file() {cout<<"Save the file"<<endl;}
};
将一个类分解成三个类，程序会更加灵活，而影响每一个类的几乎就只有一种原因，目的也就达到了。