将一段经常需要使用的代码封装起来,在需要使用时可以直接调用,这就是程序中的函数。这是在百度上搜到的一个定义，也是程序中函数存在的最基本的理由。
随着代码规模的不断增大，我们需要不断地封装提取函数，这是为了代码的层次更加清晰。否则的话，一个拥有十万行代码的函数，对于读者来讲，将是一场灾难。随着现代编程理念的兴起，大家对于函数提取的关注度也到达了空前的高度，没有人会写出一个具有几千行代码的函数，因为，大家都知道这是典型的烂代码。别的不说，为了不让别人耻笑我们的编码水平，我们也不会允许这样的情况发生。因此，会提取函数，多用函数，多用短小函数，逐渐成了一个编程高手的特征，程序员也在超这个方向努力。可是，函数短小，多提取函数一定就是编程高手吗？我们真的“会”提取函数吗？
让我们来看几个例子：
例1：对全局变量进行封装
switch.c
int switch = 0; // 某个开关，0：表示关，1：表示开
int getSwitch()
{
return switch;
}
file.c
void foo()
{
if(1 == getSwitch（)) //如果开关打开
{
//do something
}
}
上面的用法有两个问题，第一，封装函数本身没有起到任何作用，因为获取出来一个全局变量进行操作，跟直接对全局变量进行操作没有区别，也就是说，用函数来获取全局变量，没有体现实质性的好处。第二，为什么用注释，因为单靠代码没有办法自注释地说明if(1 == getSwitch（))代表什么意思，是开还是关?所以需要用注释来补充说明。
这是一种典型的为了用函数而用函数的做法。一旦这个函数处于系统的一个咽喉要道，并且无法inline的话，该函数的调用开销可能成为系统性能瓶颈。弄巧成拙，得不偿失。
其实干干脆脆这样用，就很好。在程序表达力方面，没有任何削弱。
void foo()
{
if(1 == switch) //如果开关打开
{
//do something
}
}
如果有更高一点的追求，想要用函数进一步增强表达力，可以这样：
switch.c
bool isSwitchOn()
{
return (1 == switch);
}
file.c
void foo()
{
if(isSwitchOn（))
{
//do something
}
}
这样的函数封装才是有意义的，函数起码表达了一种语意，语意表达出来了，注释也就自然没有必要了。所以，当要加注释的时候，就需要问问自己，这个函数设计的是否到位。
例2 用类对数据进行封装
尤其对于面向对象入门不久的程序员，看到什么都想要用类。例如下面这样：
struct
{
string name;
int age;
}Person;
void foo(Person person)
{
// 如果年龄大于60岁，把姓名打印出来
if(person.age > 60)
{
printf("name = %s\n", person.name.c_str());
}
}
有些人看着不爽，马上把它变成面向对象：
struct
{
void setName(string name)
{
this.name = name;
}
void setAge(int age)
{
this.age = age;
}
string& getName()
{
return name;
}
int getAge()
{
return age;
}
private:
string name;
int age;
}Person;
void foo(Person person)
{
// 如果年龄大于60岁，把姓名打印出来
if(person.getAge() > 60)
{
printf("name = %s\n", person.getName().c_str());
}
}
上面这种所谓的面向对象，又是一种典型的为了面向对象而面向对象的做法，因为没有看到面向对象带来的任何好处。封装成类，把数据成员private起来，但是却对外提供了所有数据成员的get方法和set方法。这样等于把所有数据都暴露无遗。相反带来了两个问题，一是例1中可能存在的性能问题，二是代码行数明显比原来多出很多。相比之下，不用类封装直接操作数据显得更简洁直接。
面向对象表达的一定是一个完整概念，它所对外提供的接口，一定是它自己的逻辑属性。这样才更具表达力。上面的例子可以这样使用面向对象：
struct
{
Person(string name, int age) : name(name), age(age)
{}
void printNameWhoseAgeMoreThan60()
{
if(age > 60)
{
printf("name = %s\n", name.c_str());
}
}
private:
string name;
int age;
}Person;
void foo(Person person)
{
person.printNameWhoseAgeMoreThan60();
}
重构完之后，表达力大大增强，自然而然的，注释也不需要了。这其实也是一种常见的重构手法，Martin Fowler的《重构》一书中叫做move method。当你发现者一个对象A，把对象B所有的数据都一一取出，然后进行逻辑操作时，其实这个逻辑操作应该归属于对象B，把这个逻辑运算操作提取成一个方法，置于对象B中，就完成了一次move method操作。这样对象B就可以把自己的数据真正私有化起来，只对外提供一个逻辑运算的接口。同时也遵循了迪米特法则（最少知识原则），即一个对象对其它对象应该有尽可能少的了解，关于设计原则，展开来讲内容很多，这里暂且打住。
我们所维护的代码中有很多这样的代码，有兴趣可以尝试一下，一小步一小步把代码重构的更简洁漂亮，是一件很有意思的事情，这样才可以让编码这件事情少几分枯燥。这是重构的范畴，在此按下不表。
函数用于逻辑分层
最后再说一下函数一个很重要的作用，用于逻辑分层。
还是用例子来说话：
void foo()
{
wearPants();
if(cold)
{
wearSweater();
}
else
{
wearTshirt();
}
brushTeeth();
washFace();
}
上面这个函数的作用是，一个人起床后干的几件事情。穿衣，刷牙，洗脸。大家有没有发现一个问题，穿衣的细节和刷牙、洗脸本身不属于同一逻辑层次。
重构成如下形式：
void dress()
{
wearPants();
if(cold)
{
wearSweater();
}
else
{
wearTshirt();
}
}
void foo()
{
dress();
brushTeeth();
washFace();
}
重构后的代码清爽了很多，进入foo，看到三件事情：穿衣，刷牙，洗脸，很符合人的逻辑思维习惯。有些读者不想关心你是先穿裤子，还是先穿上衣，冷了穿什么，热了穿什么(那他们只需要知道有dress这个函数就行，dress函数如何实现不关心)。只有感兴趣的人才会去关注具体穿衣服的细节(进入dress的具体实现)。但是重构前的那种写法，导致读者没得选择，不得不把细节全部过一遍。
只有函数分层合理了，我们才能分离关注点，我们所谈的代码可读性才能真正得以实现。同时代码的可维护性也提升了，进入到某个小函数内部，更容易把握它的全局逻辑，更容易让我们集中精力去思考我们关注的逻辑。如果所有逻辑都在一个大函数中，可以试想一下会是何种混乱局面，这种情况下往往很容易被其它东西干扰，导致错误百出。
summary
所以，用好函数，是一件很值得去思考的事情。函数的使用方式可以多种多样，但是个人觉得一个原则很有用：那就是要考虑自己做函数提取和封装的目的什么，我们这么做之后有没有到达预期效果，有没有体现什么好处。这也是文章一开始的图片想表达的思想。
