大型系统的挑战

不知道LZ有没有统计这个类一共有多少个使用的场景，如果可能的话，是不是可以在Point2D中加入一个自动转换的方法  NewPonit2D AutoConvert( ),  将这种动态的旧类根据特定的属性（如： attribute.key().contains(" the atrribute")之类的判断）  转换为新类返回， 并返回新类的父类

这时候大规模改动Point2d风险太大了。
可以考虑提取父类实现纯几何意义的2D点，然后再用策略模式实现各种语境下的不同含义：“在不同语境下有不同的物理含义，比如"标注点", 三维点，等等”。
这样Point2d改动不太大，几何含义物理含义也分开了，经常变化的点也可控。

的确，风险是很大。实际情况是，现在系统不是运行得好好的，我只是单纯为了重构而重构。
1.我们现在添加功能，都是件很麻烦的事。
2.经常出一些很隐蔽的错误。调试需要花很多时间。
3.基于底层几何库的上层，对于几何库的错误，编程的时候有些人会采取对返回结果修正的方式编程。
4.由于物理逻辑没有从几何逻辑中抽出来，和这些物理意义相关的逻辑，实际上，在系统的不同模块都有类似的代码来处理。
所以，改变收益是很大的，风险是可以接受的。要是我们有单元测试就好了，哎～～～～～

场景我大概看了一下，数千个地方。按照你的做法我必须去读他们如何使用这个点类，然后判断是否可以用单纯的几何类替换。原来我也是这么想的，但是代码的质量的确不高，很多地方职责耦合太过严重。很多地方难以区分是否是单纯的几何运算。

在一些历时较久的系统中总是很容易出现这种问题。
我现在的理解，觉得根本原因在于，某些功能划分不清楚，没有明确功能的负责人，或者没有明确功能的所属模块。毕竟设计时总会有一些遗漏，当功能进入编码阶段，又不一定能及时反应过来。
所以我觉得，分散在各处的相似代码、修正代码等等一定是要收回来的，要不然意义不大。

大型系统？没有单元测试吗？

按照LZ的情况，要收回来的成本太大，如果Point2D是属于底层类，并且被引用的次数比较多，证明基于这个类的功能和组件也很多。如果引用的地方很多，按一定机率来算产生新bug的地方起码上百个地方，而这些地方又会导致上层逻辑的出错，所以这个方案等于将系统推翻了。 但问题在于LZ希望将抽象和实现分开，但是又没办法将实现全部抽取出来，这是相当纠结啊。要不就直接从现在起系统采用新的2D架构，所有人写添加新功能时必须采用新2D架构来写，这样虽然遏制了原来2D架构的不良反应，但是如果已经在旧2D架构上已经有比较多的基础功能和组件的话，新2D架构就要花不少时间来重写这些功能和组件了，而且一个系统有两种架构的存在本来就是一个错误........

统计原来的Point2D中的怪异属性被使用的场景.
针对发现的场景,用继承Point2D(x,y)或聚合Point2D(x,y)的方式产生新类,替换之.

在初步重构方案中
原来的Ponit2D对象依然沿用，但是不将其作为一个OO意义上的对象用，而作为一个门面模式。尽量保持对现系统的兼容

分析并构造新的对象。并通过原point2d来用。

这样做的目的是保持代码的清晰性和稳定性



以后新代码直接使用新对象，老代码通过搜索point2d对象，慢慢进行重够也不迟

point2d是父类，标志点，G点，都是子类