<想法>C++容易将设计思路引入歧途

C++的面向对象特性，容易将设计思路引入歧途。

    首先，以玩家数据管理器为例，基类PlayerDataMngBase，然后PlayerDataMngC和PlayerDataMngS继承它。Base类的实现在客户端、服务器都存在，而且代码必须保持一致。
    这种继承关系的出发点是“代码复用”，代码复用在我看来是绝对必须的（DRY）。但使用C++的人，想复用代码的第一反应是“继承”。
    现在看来，用继承的方式，至少有几个缺点：
    1、字面上来看，客户端和服务器确实有代码很相似的地方，但是从直觉上，客户端、服务器代码的职责和功能完全不同，使用相同的代码有些太生硬，迟早会造成冗余和“丑陋的判断”。
    2、继承的最大好处应该是多态，比如可以用基类指针操作派生类。长期开发具体逻辑，发现：这种多态完全没有任何必要（想到这一点时我有一点惊讶，而且竟然长期以来没有意识到），因为实际使用中，代码要么是在客户端，要么是在服务器，什么时候会用到基类指针？

    其次，C++的class用法，把一种十分难以理解和掌握的OO，以一种看似很容易学习的方式展现出来。（广告：只需输入不到20个字符，你就可以得到一个class，具有继承、多态等等特性，让代码更容易维护和使用，方便的扩展，你还等什么？）典型的例子是大学教程里的小汽车class，这种错误说法可能误导了一代人。
    由于容易使用，大家都可以很快的学习、使用。然而类的创建基本上没有什么规范，不同人的理解可能大相径庭，大家抽象的角度不同，而且一旦代码写好，一段时间后又被其他类复用，再想修改难于登天。初学者在项目中使用一些类技巧——对项目来说简直是灾难。

    如果项目中的程序员，都深入理解了C++ OO的表象与本质，严格按照比如Effective C++的注意事项来做，是否就能解决问题了？我觉得应该没有问题。但这个前提——所有人都理解C++，99%的情况下是不可能具备的。
    对我这样的菜鸟来说，貌似有个很实用的练习方法：复用代码，从函数和变量做起。当代码多起来的时候，class会很自然的产生。

    C++的面向对象特性——只说C++ OO的一部分，容易——而非必然，将设计思路引入歧途——在项目初期规划时难以避免。

————————————————
2010-1-13
    感谢自己把想法记录下来，提出问题，看到自己的无知。
    “其次，C++的class用法，把一种十分难以理解和掌握的OO，以一种看似很容易学习的方式展现出来。”这个看法不知所云。
    C++的class，问题应该是在于——不彻底，缺乏Java那样的动态特性；不优雅，C++代码和编译过程都不优雅；难以精通，掌握const简直是门艺术 = =！；陷阱多。

    说到这个破事，有一种我觉得很好的方法：自顶向下设计，自底向上编码。关键是后半句。
    自底向上编码、重构、单元测试，都是为了同一件事——更好更快的修改。把自己看成高瞻远瞩的设计师，预测未来需求的走向与代码堆积的走向，简直注定是要碰壁的。辛勤劳作，用工具函数来支持上层重构，用重构来改掉不佳的设计，用测试保证正确的修改。正途。

    面向对象，C++，都有可能是一个“骗局”，从未来的角度看可能是，但它是历史，渺小如我不可能评价历史。至少面向对象给无数人填饱了肚子，如果是C语言估计不行。

后记1、

    记录心得真是太好了，现在看到以前的想法，又有一种新的感受。
    最近迷上了python，经过测试，C++的渣代码运行效率是精心设计的python代码的10倍。所以C++依然具有难以匹敌的速度优势。但是python灵活性方面的优势会给人带来快乐~快乐无价。
    单元测试、OO都应该理性的面对。最近在一些设计里融合了很多想法，比如用两个函数加一个Dict实现“享元”模式，简洁而优雅。又用class扩展基本类型，也是很爽的。