基本上轉換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語言和方法之后我尤其感到如此，那么我是不是在一條正確的道路上行走呢？我是不是應該繼續我的杞人憂天，還是埋頭在代碼之中，直到“理性之光”突然降臨呢？
    總有一天，我會弄明白的。