面向对象的误会与技术选择的误区

 

面向对象的误会与技术选择的误区

吴旻

泰岩网络工作室

 

休息时和单位的同事闲聊，谈到了现在公司程序所应用的技术这个话题。他说，我们应该使用更多的现成技术，而不是自己开发。他举出一例，我们公司有一个解码程序，将接收到的FIX协议（一种金融数据协议）转换成相关的struct，如果用“cin  >>  nData”这样的方式，会方便很多；还有，如果使用ACE的网络通信功能，开发速度也会快很多，而且ACE也提供了更多的接口。

我想了一下他讲这些话的潜台词，觉得他对面向对象和使用第三方工具都有很多收获。他说得没错，至少听起来很有道理。但就像任何真理都有其范围一样，他注意到了事物的通用性，却没有考虑到事物的特殊性、复杂度以及可持续性。

从FIX协议来说，它更类似于XML协议。我见过很多XML解析器，没见过哪个是用“cin  >>  nData”这种方式来解析的，最简单的理由就是效率太差。面向对象有很多时候是用牺牲效率来提升开发速度的，但金融数据从来都是要求及时和准确的，效率几乎就是第一位的。另外，使用某些面向对向的方法，尤其是虚函数等，会大大增加调试时的复杂度。他的开发工作可能做了很多，但我相信他的调试技术一定不会太好，至少他没遇到过由于开发不慎重而给调试工作带来的巨大麻烦。

关于开发，确实有“简单的就是最好的”这么一说。但我和他的理解却有着本质的不同，我所理解的简单，是指技术和复杂度，还有可持续性。而他指的简单，其实是眼下的开发越省事越好，至于将来的事情，那就不是他的责任了。

 

对于是否使用ACE，其实我们讨论过一次了。ACE比较适合的是大型网络开发，尤其是服务器压力很大的万人级同时在线。而我们的程序只是简单使用了网络通信收发，socket个数不超过20个。大材小用不说，引入的复杂度却是了得。最简单的说，找个会socket 的程序员非常容易，差不多给个3~5K的就行，而且程序出了问题也会容易定位。可是，如果用了ACE，要是原有的程序员离开，再找一个懂的，成本就会高N多，而且相关的调试技术也不一样。另外，如果ACE发生瓶颈，或者我们的要求超出了ACE所能提供的，如何进行扩展，我们也很难找到相关人员。现成的教训就是我们使用了TimesTen数据库，在开发低数据量时，它的吞吐很及时，但当数据量大到一定程度以后，连TimesTen的技术支持人员也不知如何满足我们的需求。想想看，我们花了那么多钱购买了TimesTen数据库服务，做了那么多的开发，到最后却不得不抛弃它，这对公司是一个什么样的事情？

所有的工具都是给人用的，我们也鼓励使用先进而又方便的工具，但使用任何一种工具和技术，开发人员都应该慎重。要知道，技术人员要解决开发问题，但公司还要解决运营问题。换个角度想想，也许事情就不一样了。