面向对象？
毕业工作半年了，到现在也一点弄明白什么是面向对象，说来实在惭愧。
记得在学C++的时候（其实也不敢说是学，只是了解了一些语法而已），第一章中有介绍面向对象的思想。封装，继承和多态被称为面向对象编程的三个特性。后来，了解了封装就是把一个类中的方法和属性封在一个盒子里，外界不需要关心类方法的具体实现。面向对象编程就是面向接口编程，接口中有一些通用方法的描述，接口就是一种约定，当类中的实现方法改变时，只要接口不变，调用者就不用关心细节，甚至于换成另一种类的实现，原有代码照样不变。
也许这就是做企业软件的悲哀吧，每天累得要死，可是却很少有时间静下来思考一下自己做的东西，用的是什么思想，有些什么不足，应当怎样改进。现在做的东西的分层架构，我都不明白为什么要这样分层，这样分层的好处是什么？缺点倒是不少，DLL拷来考去的，还要关掉VS.net累死了。层与层之间用接口调用，可是几乎所有的方法都会在接口中出现，这样的接口有什么用哪？将来换做其他实现的时候要实现这个接口就要实现所有的方法，还有什么意义哪？这点我实在想不通。
上面所讲得还只是同一模块中层间的调用，不同模块之间就更不用提了。整个类在设计的时候没有很好的考虑模块间的调用问题。我想模块间的调用应该通过接口，在设计类的时候，要充分考虑到所写模块中的类要提供给其他模块什么方法，并写在接口中，其他模块要想调用我模块中的方法，只要通过接口访问我的方法就可以了。这样也就降低了模块间的耦合性。可是现在在实际开发中很少这样做，每次都是要么直接new其他模块的对象，要么干脆在自己的模块中写方法访问数据库，代码乱到了极致。我不知道这样的局面要持续到多久。
企业软件说到底，就是把数据从数据库里捞出来，呈现给客户看。怎么最快？直接从数据库里捞出来最快。可是考虑到扩展性，就只能牺牲性能，因为如果将来业务逻辑发生了变化，系统很难升级，只能重写。性能和扩展性之间是一对矛盾体，应该在两者之间取得平衡。试想一下，如果一个系统支持多种数据库，那么针对具体数据库的性能优化他就不可能用上。比如你想支持Orcel和SQL Server两种数据库，那么就不能用SqlClient来连接数据库，可是SqlClient这个命名空间中的方法是针对Sql Server数据库写的，性能比用OleDB快很多。
记得在学C++的时候（其实也不敢说是学，只是了解了一些语法而已），第一章中有介绍面向对象的思想。封装，继承和多态被称为面向对象编程的三个特性。后来，了解了封装就是把一个类中的方法和属性封在一个盒子里，外界不需要关心类方法的具体实现。面向对象编程就是面向接口编程，接口中有一些通用方法的描述，接口就是一种约定，当类中的实现方法改变时，只要接口不变，调用者就不用关心细节，甚至于换成另一种类的实现，原有代码照样不变。
也许这就是做企业软件的悲哀吧，每天累得要死，可是却很少有时间静下来思考一下自己做的东西，用的是什么思想，有些什么不足，应当怎样改进。现在做的东西的分层架构，我都不明白为什么要这样分层，这样分层的好处是什么？缺点倒是不少，DLL拷来考去的，还要关掉VS.net累死了。层与层之间用接口调用，可是几乎所有的方法都会在接口中出现，这样的接口有什么用哪？将来换做其他实现的时候要实现这个接口就要实现所有的方法，还有什么意义哪？这点我实在想不通。
上面所讲得还只是同一模块中层间的调用，不同模块之间就更不用提了。整个类在设计的时候没有很好的考虑模块间的调用问题。我想模块间的调用应该通过接口，在设计类的时候，要充分考虑到所写模块中的类要提供给其他模块什么方法，并写在接口中，其他模块要想调用我模块中的方法，只要通过接口访问我的方法就可以了。这样也就降低了模块间的耦合性。可是现在在实际开发中很少这样做，每次都是要么直接new其他模块的对象，要么干脆在自己的模块中写方法访问数据库，代码乱到了极致。我不知道这样的局面要持续到多久。
企业软件说到底，就是把数据从数据库里捞出来，呈现给客户看。怎么最快？直接从数据库里捞出来最快。可是考虑到扩展性，就只能牺牲性能，因为如果将来业务逻辑发生了变化，系统很难升级，只能重写。性能和扩展性之间是一对矛盾体，应该在两者之间取得平衡。试想一下，如果一个系统支持多种数据库，那么针对具体数据库的性能优化他就不可能用上。比如你想支持Orcel和SQL Server两种数据库，那么就不能用SqlClient来连接数据库，可是SqlClient这个命名空间中的方法是针对Sql Server数据库写的，性能比用OleDB快很多。
