凭什么要用面向对象编程(补充)

前言:本来上篇已经是完整篇,可在上篇第22楼virus的回复中,我发现了上篇文章中的最终解决方案还是存在着本质的缺陷。再看到第24楼richardzeng的回复,仔细想来,的确应该是像richardzeng的写法一样有更深一步的考虑,感谢两位的回复。我将补充方案的讲解加了进来,希望可以给大家以帮助。

 

接上篇 凭什么要用面向对象编程——面向对象重要设计原则概述


★2007-10-02  08:00 小菜在家中准备
小菜开始准备给人家讲座的内容,一开始都很顺利。可是当要把不同的验证方式给细化时,发现了问题。

 
24 原有的接口实现关系图

如果要再把是用户名密码验证,还是指纹验证的代码加进来,应该如何写具体的实现类呢?

 
25 SqlServer实现类改造
此时你会发现,如果要实现这个功能,你必须在你的每个实现类中写出上面的判断语句,如果某一天要增加一种数据访问(比如MySql)你就得再写一遍类似的代码,如果某天增加一个用户验证的方式(比如人脸识别验证),你就得改动所有的实现类的分支判断。这显然是让人难以接受的。

小菜决定换一种思路
 

26 多个类的多重继承

也就是把分支判断的语句,通过继承的方式给分解掉,这样每一种实现都体现成为一个类。只要有新的数据访问或者用户验证方式,不外乎就是增加类就可以了。应该是解决了问题。

可是,看着这张图,小菜感觉不到设计的美。如果,我们增加一种数据访问(如MySql),我们需要增加至少四个类。如果我们增加一种验证方式(如人脸识别验证),那就需要每个数据访问下都继承一个类。目前是3*3共9个类,当扩展需求来了以后,类的增加会成为一个梦魇。

难道没有办法了吗?

 

1)当想不出解决办法时,分析自己的代码有什么容易被改变的地方,可能找到解决思路


 

回到那个接口

 
 
其实当我们要增加一种验证方式时,这个Users类也是要修改的。而且对于Users类来说,验证时通常只会用到当中的一两个属性,而现实中,Users类的属性如性别、生日、姓名等等都对验证来说没有意义。此时发现,验证和用户类本身还是有区别的,验证属性其实只是用户类一小部分属性而已。对于数据库来说,我们把用户名、密码、门禁卡编号、指纹数据存到Users表里的字段中是没有问题,可在面向对象编程时,将它们混在一起的确不利于应对变化。

2)当想不出解决办法时,再次仔细分析需求,并找出需求的本质是个很好的办法

登录是为了验证用户,验证有很多种表现形式。网络上的验证通常就是用户名和密码,但随着科技的进步,指纹试别、面部试别等技术都可以成为验证用户的手段。而这一切,其本质上,验证就是抽象概念,其它都是它的实现方式。那么验证应该就是接口,那几个表现方式是它的实现类。OK,思路有了。

思路:提炼出验证接口,将不同的验证实现这个接口,将用户管理接口的登录方法聚合这个接口。

 
27 相对较好实现办法的类图

将验证分离成一个接口,不同的验证方式不过是验证的一种表现形式。

 


 
 
 

 
32 更改了原用的参数,改用验证接口

 
33 Sqlserver实现类的代码(其它实现类类似)


 
34 用户名密码登录用的界面事件代码


 
35 指纹登录的界面代码

此时,小菜算是松了口气,不管是增加新的数据访问或是增加新的验证方式,都只不过是增加一个类就可以了,这就把“开放封闭原则”和“依赖倒转原则”再次得到了充分的体现。实际上,在不知不觉中,小菜已经使用了“简单工厂模式”、“门面(外观)模式”、“桥接模式”。在这个完整的例子中,并不是为了模式而模式,而是在需求的变更中,为了应对需求的变化而不断演变出来。相信以后需求再有变化,也可以从容面对。

最后,小菜在新建文档的标题处打上“凭什么要用面向对象编程”,开始培训材料的写作。

附:有朋友质疑一个登录功能写这么多的代码的必要性。我想说的是,这是一个讲解面向对象编程的例子,为了理解的需要,杜撰了一些需求的变更。通过这样的讲解,是希望你可以在你的编程工作中,学会如何去设计和考虑问题,更好的应用面向对象技术来创建可维护、可扩展、可复用,并灵活性好的程序。

源代码下载

 

 


 

posted on 2010-05-27 13:15 伍迷 阅读(...) 评论(...) 编辑 收藏

导航

公告