面向对象编程被过度使用

有时候最好的答案就是简单的答案。

我有争议的观点是John Carmack(游戏邦注:代表作有ID Software, Quake等)并不是一个优秀的程序员。

不要误解我的意思，在我看来他是一个非常聪明的程序员，但当我注意到quake源代码中的“#define private public”这一行后，我不禁认为他是一个无论如何都能完成工作的人，但在我的定义中，他不是一个好程序员:) 这个观点让我陷入了很多激烈的讨论;)

c++是未来的杀手级语言…

．.． 动态语言。

没有人拥有它，它有越来越多的特性，比如编译时(元)编程或类型推断，没有函数调用开销的回调，不强制单一方法(多范式)。POSIX和ECMAScript正则表达式。多个返回值。你可以有命名参数。等等。

编程的过程非常缓慢。JavaScript花了10年的时间才起步(主要是因为性能)，大多数用它编程的人仍然不理解它(JS中的类?来吧!)我敢说c++将在15-20年后真正开始发光。对我来说，这似乎是c++(语言以及编译器供应商)和当今使用动态语言编写的程序员的适当时间。

c++需要变得对程序员更加友好(编译器错误是由模板或编译时间生成的)，程序员需要意识到静态类型是一个福音(它已经在进行中，参见这里断言用动态类型语言编写的好代码就像编写静态类型语言一样)。

MS Access*是一个真正的开发工具，专业程序员可以毫无羞耻地使用它

仅仅因为某个平台吸引了自认为是程序员的黑客和秘书，就不应该玷污这个平台本身。每个平台都有其优点和缺点。

那些抱怨某些平台或工具或将其贬低为“玩具”的程序员更有可能对自己的手艺知之甚少，而不是他们的自我意识所说服的那样。对我来说，听到一个程序员抨击任何他们自己没有广泛使用过的环境是一种过度自信的表现。

*在这里插入任何恶意工具(VB, PHP等)。

JavaScript是一种“混乱”的语言，但上帝保佑我，我喜欢它。

布尔变量只能用于布尔逻辑。在所有其他情况下，使用枚举。

布尔变量用于存储只能有两个可能值的数据。使用它们所产生的问题经常被忽视:

程序员通常不能正确地识别某些数据何时应该只有两个可能的值 指导程序员做什么的人，比如程序经理或编写程序员遵循的规范的人，通常也不能正确地识别这一点 即使一段数据被正确地识别为只有两种可能的状态，这种保证在将来也可能不成立。

在这些情况下，使用布尔变量会导致令人困惑的代码，这通常可以通过使用枚举来避免。

例子

假设一个程序员正在为一家只销售轿车和卡车的汽车经销商编写软件。程序员为他的软件开发一个全面的业务需求模型。由于知道所销售的车辆只有轿车和卡车两种类型，他正确地识别出可以在Vehicle类中使用一个布尔变量来指示车辆是轿车还是卡车。

class Vehicle {
 bool isTruck;
 ...
}

这个软件是这样写的，当isTruck为真时，车辆是一辆卡车，当isTruck为假时，车辆是一辆汽车。这是在整个代码中执行多次的简单检查。

一切都很顺利，直到有一天，汽车经销商收购了另一家同样销售摩托车的经销商。程序员必须更新软件，使其能够正确地考虑到经销商的业务发生了变化。现在它需要识别车辆是汽车、卡车还是摩托车，这是三种可能的状态。

程序员应该如何实现这一点?isTruck是一个布尔变量，所以它只能保存两种状态。他可以将其从布尔类型更改为允许多种状态的其他类型，但这将破坏现有的逻辑，并且可能无法向后兼容。从程序员的角度来看，最简单的解决方案是添加一个新变量来表示车辆是否是摩托车。

class Vehicle {
 bool isTruck;
 bool isMotorcycle;
 ...
}

代码更改后，当isTruck为真时，车辆为卡车，当isMotorcycle为真时，车辆为摩托车，当两者都为假时，车辆为汽车。

问题

这种解决方案存在两个大问题:

The programmer wants to express the type of the vehicle, which is one idea, but the solution uses two variables to do so. Someone unfamiliar with the code will have a harder time understanding the semantics of these variables than if the programmer had used just one variable that specifies the type entirely. Solving this motorcycle problem by adding a new boolean doesn't make it any easier for the programmer to deal with such situations that happen in the future. If the dealership starts selling buses, the programmer will have to repeat all these steps over again by adding yet another boolean.

软件的业务需求发生变化，要求他修改现有代码，这不是开发人员的错。但是首先使用布尔变量使得他的代码不那么灵活，也更难修改以满足未知的未来需求(不那么“适合未来”)。当他以最快的方式实现更改时，代码变得难以阅读。使用布尔变量最终是一个不成熟的优化。

解决方案

首先使用枚举就可以避免这些问题。

enum EVehicleType { Truck, Car }

class Vehicle {
 EVehicleType type;
 ...
}

为了在这种情况下容纳摩托车，程序员所要做的就是将Motorcycle添加到evhicletype中，并添加新的逻辑来处理摩托车的情况。不需要添加新的变量。现有的逻辑不应该被打乱。不熟悉代码的人也很容易理解车辆的类型是如何存储的。

悬崖笔记

不要使用只能存储两种不同状态的类型，除非您绝对确定两种状态总是足够的。如果将来可能需要两个以上的状态，则使用枚举，即使布尔值可以满足现有需求。