代码抽象

代码抽象的三个境界

软件开发时，我们总是既想要使用别人写好的代码，又希望自己写的代码尽可能的重用。想要这两个目标都实现，离不开抽象化.

不要重复自己

软件工程名著《The Pragmatic Programmer》首先提出这个原则。他的涵义是，系统的每一个功能都应该有唯一的实现。因此，在这个境界的人通常都会使劲封装。为了追求完美也好，说代码维护方便也罢。在这个境界的程序猿通常认为自己封装是最棒的。

你不会需要它

到了第二个境界，可能会思考。这个抽象是否有意义，抽象了之后是否能缩小需求变更的带来的影响。其实，大多数时候的认为以后有意义的抽象，到以后回过头来看，并没有意义。因此，这个层次的境界，会提醒自己没有必要徒增抽象、徒增工作量，把这些时间花费在有意义的工作上更好。

三次原则

最后的境界是前两个境界的融合、贯通。这个原则明确的给出了三次这个数字。当一段代码出现重复、冗余时，不要马上去抽象、而是等这个冗余达到三次，才去处理。这样做有几个理由:

• 省事。如果一种功能只有一到两个地方会用到，就不需要在“抽象化”上面耗费时间了。
• 容易发现模式。“抽象化”需要找到问题的模式，问题出现的场合越多，就越容易看出模式，从而可以更准确地“抽象化”。

三次原则的“三”其实也是一种抽象，但是1次抽象浪费时间，2次抽象发现不了规律，等到4次5次也许又觉得当初为什么自己不“抽象化”这段代码。所以为何不给自己定一个死规矩呢？这样以后团队合作，如果发现团队中有段一模一样的代码出现4次没有抽象，就可以以此为规范，来指出这样的代码应该重构。以上！