大型系统的挑战

我的意思：采用template比oo的弹性大得多，你如果重构，可以考虑用template来做。

把point2d换个名字不是太复杂的事情，因为编译器会替你检测所有的错误，你只要保证换名称后能编译通过即可；麻烦的是这20个人都得负责改这个名称。

Command+Shift+R, problem solved
要学科学用科学

弹性大归大，但是修改量是相当恐怖的。其实我的向量类Vector<Real>是用模板做的，但后来发现其实没有必要。
1.我不需要提供不同的精度。double即满足我们的精度需求。
2.我不需要提供不同的坐标系。我们都是以直角坐标系建模，极坐标系等不用考虑。

可是需求不是给类换名字，汗...

这个template不是用来考虑你的数值精度的，而是用来考虑的的体系结构。
比如从你的描述看，template<class Point, class Property> class PointBinder 这种结构比较容易使用。而你的处理器完全可以这样：template<class PointT> void processor(PointT & p)
{
    proc_point<PointT::point_type>(p);
    proc_property<PointT::property_type>(p);
}
你的这个Property完全可以不定义，而这些都用traits来处理。如果Property是一个空类型，proc_property这个模板函数直接被优化掉，根本不需要生成代码。这些都是编译器来搞定，不需要你去关心。
这样代码相当的直观，而不是oo那样到处是接口，而且至少必须提供一个空指针，你的维护就来了，而且修改接口，涉及到的都需要懂。template基本没有这些麻烦。

我觉得用template的目的，主要还是将逻辑和类型解耦，而直接针对概念编程。
比如distance(Point p1, Point p2);从共性上来说，无论Point是MyPoint还是YourPoint;是double还是float; 是直角坐标系、极坐标系还是自定义坐标系; 是2D还是3D点。distance都应该是一个接口，这时用template是非常适合的。
但是此处对于我来说，我是有很多点的类型，但是几何点只有一个，而不是多个。对于其他的含有物理逻辑的点类型来说，共性是很少的，比如一个物理逻辑点，他只能被命名为"xPoint", 他只能出现在区域[-1, -1], [1, 1]。这些非通用的算法你只能是把它作为这个类的成员函数。

对于你说的修改接口，需要的地方都需要动，用template也是一样的。

其实我这里的问题，和语言关系不大，和是不是用template关系不大。再好的技术也是人用，用不好还是一团乱。

怎么说呢，attributes ,name，动态语言。。。

最简单的做法就是弄个基类，只有 x y 两个属性，什么 get set 倒不是必须的，把现在这个类设为它的子类

下一步把用不到 name attributes 等属性的函数替换成这个新识别出来的基类

这个类貌似还缺一个 toString

写个代表几何逻辑的Point2D父类，让旧的和新的point2d算法逻辑类都继承这个父类，新旧代码所有Point2D算法逻辑类全部重构成新的父类，以后再加新算法的时候再多个子类，这种方案行不？  我觉得如果算法会经常变的话，用工厂模式可以会好点