OO——从不知到知道一点,从迷茫到豁然开朗 (迟来的我的2002到2007)


前两天写了一个 “ 使用了继承、多态还有工厂模式和反射,但是还是没有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就是这么个东东,学的时候根本就不能想具体的实现代码,只能想大体的情况。如何设置基类,设计几个属性、设置几个函数、几个事件,这样就完事了,至于如何实现是另一回事了,呵呵。

还是要感谢一下伍迷,多亏了他的小菜系列。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值