头等“医者”:架构,让编译器消灭Bug。
看过一篇博客《我是怎么教媳妇面向对象编程的》,让我真正的理解到了面向对象的概念。比如定义一个接口:
interface ISwitch
{
void TurnOn();
void TurnOff();
}
当我们看到一个类继承了这个接口之后,我们立刻就明白了,这一类对象都有一个开关的功能,我们就可以直接去了解这个类是用来开关什么的,是自己,还是隔壁房间的吊灯。好的设计可以让我们很快的明白这一类对象可以用来做什么,有什么功能,需要我们去做些什么。。。。。。
可能有人觉得自己只是最底层的程序员,架构离自己似乎太遥远了。我觉得不是这样的,从一个属性名,到一个函数的定义,一段代码的实现,一个类的设计,一个模块的设计,这些都是架构,每一步都需要我们去仔细的推敲。
假如我们在写一个有关图像的类,需要提供一个函数用来保存图像,他可以是这样的:
void SaveImage(string path);
他也可以是这样的:
void SaveImage(Path path,string Name,EnumType type);
两种定义方式又有什么不同呢?来表达一下我的理解。
第一种方式,比较简单。但是假如我作为一个后来才加入项目组的新人,可能就会有这样的疑问了:
- 传的参数是一个path,我需不需要在验证这个string是不是要给正确的路径之后再使用,换句话说就是这个函数的实现是否负责路径的验证,
- 都支持什么格式的图片存储,是只支持一种,还是常见的几种,还是可能会有其他的自定的格式。
第二种方式,从定义上面看就可以明确的看出来,我需要传一个正确的路径,支持的保存格式都在EnumType里面;再使用的时候编译器也会去检查传入的实参是否正确,可以避免一些”不小心“。
机器都是死板认真的,人呢都是会出错的,让机器去帮我们避免一些错误,这才是机器存在的价值。