基本上转换erwin的xml文件的python程序已经就绪了，但是在写程序和考虑问题的这几天里我反而有些糊涂起来，关于程序的设计和设计的选择一直困扰着我。
    说到那个python程序，我已经重写了很多遍了，Martin最初的那个程序其实很简单，他的需求其实也没有那么难，但是我把程序写过几遍以后发现了一个问题：我每一次都可以用完全不同的思路来解决这个问题，以至于我的程序都完全不一样。我可以完全使用python内置的dict和tuple对象来存储所有的Entity、Attribute、Key和Relation的信息，我也可以做一个Classitis，把所有能看到的结构都映射成为class defination，我甚至也想过functional的解法：利用一个map结构，让每一个节点的数据通过一个方法的管道，然后在管道的另外一边读取我需要的信息……
    在Java里面，一切都很简单，我只需要定义interfaces，他们必须遵守的契约，然后我可以在实现类里面实现我的解析过程，构造出我想要的对象结构，一切都顺理成章，我可以利用interface来隔离各个模块之间的耦合，比如对某一个parser的依赖关系，对于特定dom版本的依赖关系，对于dom的依赖（我想这个需求是合理的，因为我们完全可能因为内存消耗的原因而转换到sax），甚至对于xml文件的依赖（当然，这样我的设计就走得太远了），然后通过IOC的方式把他们粘合在一起，我的程序就完成了。甚至于我可以这样说，也许我的实现是naive的，也许我的代码是低效的，但是我的思路是正确的，至少，reasonable。
    在python里面我找不到这种感觉：我觉得无论哪一条路都是可行的，OO的方法,functional的方法，甚至于过程化的方法都是可行的，然而又都是不太完美的，我也许可以使用在java里的经验，但是我隐隐约约觉得会有更好地解决方案，由于这样的原因（也许因为懒惰），我没有做那样的尝试，怎么说呢，我觉得那样兴师动众的方法在一个动态语言里太——不优雅了。在我多少了解一点functional语言和方法之后我尤其感到如此，那么我是不是在一条正确的道路上行走呢？我是不是应该继续我的杞人忧天，还是埋头在代码之中，直到“理性之光”突然降临呢？
    总有一天，我会弄明白的。