前两天写了一个 “使用了继承、多态还有工厂模式和反射，但是还是没有OO的感觉。 ”，看到了很多同学的回复，自己又反思了几次，终于有所感悟，写下来做个记录。
一、先说一下我学程序的经历。
我是97年在高一的计算机课程里第一次接触编程语言——QBasic。刚接触根本就是什么都不知道，菜到什么程度就不说了，但是对编程很感兴趣，高中三年也多少写了几行的代码吧，都是basic的，都是一行一行地，写函数都很少用。写程序呢也都是自己写着玩的。
由于对计算机感兴趣，又加上成绩也不怎么地，所以呢我是选专业而不是选学校（也没有那个能力:)）。最后考到了市电大的计算机专业。第二学期开始学习汇编语言，幸亏有basic的基础，还能看得懂。第三学期学习C++、数据结构，第四学期学习VB6.0。
所以编程方面一直都是面向过程的思路，只是在C++里面知道了有个类（class）的东东，其他的关于面向对象就不知道了。
02年初开始上班了，用的还是vb6.0，作sp的开发，也就是短信，业务逻辑也很简单，也还是面向过程。这时候我才会使用SQL 2000。
03年换了一家公司，开始使用asp.net了。那时还是 vs2002呢。一开始使用C#。面试我的技术经理使用的是C#，给了我一段他写的代码让我去读懂（当时我还不会.net呢）。读了不到一周，大体上是看懂了。很幸运居然通过了面试，开始正式使用和学习.net。
上班后发现一个问题，除了经理，其他的程序员都在用vb.net，于是又改用vb.net来写程序，毕竟以前一直在用vb，所以感觉很亲切。写的程序是一个有点像OA的东东，给一个公司定制开发的。写的代码也都是事件驱动，根本就没有类的感念。
04年上半年又换了一家（好像换的有点勤），这个就不说了，失败呀。 上半年又换了一家，感觉这时候才开始“正式”学习.net（这时已经使用vs2003了）。对于程序不仅仅停留在会用就行了的阶段了，开始研究更高一点的东东了，具体点说呢就是基本类库，服务器控件等。
我一开始使用.net的时候（03年）就是使用类似于sqlHelp的自己写的help来操作数据库，现在有时间来完善和扩充功能了。一开始是很简单的了，然后是一点一点地增加功能。
完成任务之余开始编写服务器控件，主要有两个：分页控件和联动下拉列表。一开始是根本就不会用控件，找了一本书开始试着写。控件是使用vb.net来编写的。原因很简单：一是亲切、而是vb.net的IDE很友善，很适合于初学者自己琢磨，因为提示很多很详细，很多在C#里没有的提示在vb.net里面都有。比如说枚举的提示。
我写的分页控件和吴旗娃的那个不同，吴旗娃的只工作在UI层，分页的算法和访问数据库的功能都不在他的控件内部实现，需要在控件外部实现，当然这样就很容易兼容不同的数据库。而我的呢把分页的算法和访问数据库的功能都包含在控件内部了，所以调用起来是很方便和简单的。好像有点跑题了。
总之前几年是根本就没涉及到面向对象的东东，流行的三层我也是不用的，感觉三层要写很多的代码，太累了，因为是我一个人写代码嘛，写那么多的代码多累呀（那时候代码生成器还没有现在这么流行呢）。而我自己早就有了自己熟悉的写代码的方式，为什么要改变呢？
二、开始说OO了
开始学习面向对象还是在去年吧。又换了一家公司，这个公司比较奇怪，来了之后先学习OO的基础，借着这个机会才把封装、继承、派生、多态、委托、接口学习了一遍，其中委托、接口还是一知半解，前面的几个也没有完全理解。可能使学习的不好吧，被炒了。这还是头一回呀。
以为自己已经被淘汰了，已经到了不会OO就没有工作了的时代了。但是还得有个工作来糊口哇，于是又找了一家。在这里才渐渐恢复了自信。发现原来OO的时代还没有到来，不会OO还是可以找到工作的。
但是OO还是要会一点的，设计模式也是要学习一下的。于是呢在工作之余继续学习OO和设计模式。理解了封装、继承之后呢，在自己的程序里面使用了一下，感觉还是比较方便的。于是继续学习。但是这之后就感觉内什么进展了，因为换成了OO的方式，我的代码会成倍的增加，没有必要吧。
好了终于说到了前几天的事情了。我们遇到了这么一个需求：我们公司有好多客户，每个客户用的软件都不太一样，有的是OA，有的是CRM，有的是OA + 定制开发。但是呢每个客户都可能需要实现收发短信的功能。于是就有了那篇帖子。
客户的需求是不断变化的，短信的种类也是不定的，会不断地增加短信种类，和修改短信的处理过程（也就是业务逻辑了）。我们有好几个组，每个组都负责不同的项目和客户，每个组都有可能会涉及到短信的处理这一块。
很显然短信的处理方式要写成一个通用的，就是每个小组都可以用，每个项目（OA、CRM、定制开发），每一个客户都可以使用。短信处理有固定的部分（接收短信和发送短信）和变化的部分（短信的具体的处理方式）。于是我就想把固定的部分写成一个 winfrom 程序（A项目），在服务器上运行；变化的部分写成一个单独的项目（A项目），然后编译成dll，在由A项目来引用（通过反射来调用）。这样A就可以大家一起用，一起升级；B项目根据具体的情况具体编写。
这样就方便多了，谁也不会影响谁，既可以各干各的又可以“共享”通用部分的代码。
实现的代码已经在那篇文章了写了。可能题目写得不明确吧，“没有OO的感觉”说的是，写完了之后感觉并不是OO的方式，还是用的面向过程的思路，于是有了这个题目。
有同学说要使用触发器来实现，触发器是可以实现的，这点我承认，但是有很多的缺点：代码多，不便于阅读；不便于扩展、不便于分工。说具体点：如果用了触发器的话，那么以后关于短信处理的或就都归我了，因为别人看不懂，想帮都帮不了忙。
关于触发器我就不多说了，昨天晚上和他QQ聊了很久，太累了。
最后说一下我对OO的理解吧。记得神雕侠侣里面有一段情节，就是杨过学了好多的武功，感觉每一种武功都有优点，同时也都有其缺点，不知道该用哪一种武功好，自己一个人在山石上和几，练习，思索，甚至会发狂。几天过去了，最后终于领悟到：管他是哪门哪派的武功，对方发什么招式，我用什么招接最好，我就用什么招。管这一招是哪一门那一派的呢，管他的上一招是什么下一招是什么呢，完全拆开来为我所用。那么我们写程序是不是也可以这样呢？
现在回过头来看看那段代码，如果使用case 来实例化不同的子类的话，那是不是就成了简单工程了呢？如果使用了接口那是不是就成了策略模式了呢？如果A是发布者，B来订阅，那是不是有成了观察者模式了呢？但是实际上什么模式都不是，只是一个使用了反射来调用子类的一段代码。
实现功能、实现我想达到的目的就行了，管他用的是什么呢？有关系吗？
有同学说这段代码是“DAL和BLL”混在一起的，这个对于我来说是比较特殊的，
string strSQL = "select * from inbox ";
DataTable dt = dal.RunSqlDataTable(strSQL);
这段代码是 DAL还是BLL呢？我现在是写在了 所谓的 BLL里面了，但是如果要把它分出去写在DAL里面会怎么样呢？DAL里面只有一行，BLL里面再调用一下（还是只有一行），我感觉这样是很没有必要的。
如果他说的不是要把这样的代码分离出去的话，那我也找不到要把什么样的代码分离到 DAL里面了。
另外 dal.RunSqlDataTable 是类似于 SQLHelp这样的help 是通用的。所以对于我来说基本上是没有DAL的概念了。
好像还有点什么要说的，想不起来了。太晚了先写这点吧。
ps:
我一开始学OO的时候，看到大家举的例子，什么猫了、狗了、汽车了什么的，这个郁闷呀，我的代码里哪里来的什么猫叫、狗叫的，这叫我怎么写呀。其实OO就是这么个东东，学的时候根本就不能想具体的实现代码，只能想大体的情况。如何设置基类，设计几个属性、设置几个函数、几个事件，这样就完事了，至于如何实现是另一回事了，呵呵。
还是要感谢一下伍迷，多亏了他的小菜系列。