您把哪些东东看成了对象?

     我们初学面向对象的时候,书里面往往会用小猫、小狗、鸭子、汽车等举例子,说是可以把这些看成是一个对象,然后再弄出来一些属性、方法、事件等进行说明。

     然后呢我们学会了这些,要在一个小的项目里面应用一下,比如网上购物网站的时候,我们按照这个思路来设计,我们会把商品看成是一个对象,把购物车、订单看成是一个对象,把客户、管理员看成是一个对象,然后寻找他们之间的各种关系,于是抽象、接口、实体类等等被一一设计出来。

     这似乎没有什么问题,大家是不是也是这么做的呢?如果是这么做的话,那么大家有没有发现这里面有点小问题吗?

     我还是先说一下我的做法吧,还是上面的网上购物网站的例子,我会这么做:

     网上购物,要先有一个产品信息的列表页面(A 产品列表),点击一个产品后会显示该产品的详细介绍(B 详细介绍),如果满意的话,客户会把这个产品放在购物车里面(A 购物车列表),选好了产品之后客户会填写一个订单(C 表单),添加订货人、收货地址等,提交之后就会看到一个订单的列表(A 订单列表)。

     对于管理员来说也会看到一个产品的列表(A 产品列表),如果管理员想要增加新的产品的话可以单击“添加”按钮,打开一个表单(D 表单)来添加信息。管理员也可以看到客户的信息列表(A 客户列表),然后可以查看客户的详细信息(B 详细介绍)。当然管理员还可以查询产品、删除产品、客户信息等。

     请大家看看括号里的A、B、C、D,没错,一个网站对于我来说就是由列表、表单、详细介绍等部分组成的,也就是说我把这些都看成了对象,而且好像还是“抽象基类”,列表可以“变化”成前台的列表和后台的列表,然后呢又可以“变化”成产品列表、客户信息列表、订单列表等等。

     这里用了“变化”而没有使用“继承”,是因为表面上看(或者是面向对象的习惯上来看)是派生了各种列表,但是实际上我的做法并不是继承的哪种形式。所以这里的抽象基类也用引号引了起来。

     两种做法都说了一下,先看看我前面提的那个小问题吧。

     对于第一种做法来说,我们在做一个网上购物网站的时候要建立商品类、订单类、购物车类等,这个项目做完了之后我们做下一个项目的时候,假设我们下一个项目是CRM,那么我们就要建立另一套实体类,当我们再做OA的时候,又是完全不同的一套实体类。

     即使是同一个项目,商品类和订单类也不尽相同,但是又很类似。类的属性是不同的,但是代码里面,除了属性名称变化了一下,其他的代码是不是一样的呢?

     我的方式,就是把列表、表单、详细介绍等看成了对象,也可以说是把数据库本身看成了对象, 以达到以不变应万变的目的,不管是什么样的网站(静态的除外),都是离不开列表、详细介绍、表单等功能。我研究的对象就是这些。

     既然现实世界里的小猫、小狗、鸭子、汽车、书等等都可以看成是对象,那么数据库为什么不可以呢?以前有人讨论book.Save是否够OO,而我的想法是 “数据库.Save”,不对,应该是“表.Save”,就是

表.Name = "产品" 表.Save()

     当然这么做就会有一个很大的局限:必须使用数据库!

     其实这种做法只是针对那种需要使用数据库来保存信息的项目,如果您的数据是保存在内存、XML、Txt等里的话,那么很显然这种方法就不适用了。

     虽然有局限,但是对于我个人来说,这个使用范围也是相当的大了,这个也够我研究好几年的了。

     我想做一个架构,这个架构的使用范围就是:使用数据库保存数据。

     这里的数据库指的是SQL Server这类可以使用SQL的关系型数据库。

     这样做的好处是很大的,不管是什么样的网站(动态网站),都可以看成是由列表、详细介绍、表单、查询等部分组成的,那么如果能把这些基础“部件”研究好了,让他们的适用范围更广,功能更强大的话,那么网站的实现代码就会很少。也很方便。

     我研究列表,也就是说如何把数据从数据库里面弄出来,放在页面里面,还要能够很方便的和没工作的HTML结合起来,于是“餐盘原理”就出来了。餐盘原理的目的就是解决在网站里面用列表形式显示数据的问题。这个做好了,无论是产品的列表还是购物车的列表还是订单的列表,对于我来说都是没有区别的,唯一的区别就是,数据存放的位置不同而已。

     列表的另一个主要部分就是我的分页控件,也就是QuickPager。我以前做网站的时候,这个QuickPager占据了网站的50%以上,只要给它的属性赋好了值,那么也就相当于完成了一个表单页面(当然HTML部分是由美工出的)。

     我研究表单,于是弄出来了一个表单控件,经过不断地完善、修改升级,现在已经基本可以应对很多种情况了。

     当然,您可以说我举的例子太简单,没有复杂的业务逻辑而言,如果遇到了复杂的业务逻辑,我的方法就不适用了。

     这个我承认,但是我也相信另一句话:由简入难。

     先把简单的做好了,然后再去处理复杂的情况。

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏铭毅天下

Elasticsearch聚合后分页深入详解

1、Elasticsearch支持聚合后分页吗,为什么? 不支持,看看Elasticsearch员工如何解读。 ? ? 这个问题,2014年在gith...

96511
来自专栏小文博客

SkinMaster(原LOL换肤大师)同步更新——小文’s blog

5606
来自专栏java一日一条

为什么做java的web开发我们会使用struts2,springMVC和spring这样的框架?

今年我一直在思考web开发里的前后端分离的问题,到了现在也颇有点心得了,随着这个问题的深入,再加以现在公司很多web项目的控制层的技术框架由struts2迁移到...

1351
来自专栏我是攻城师

程序员最恐怖的梦魇是什么?

2604
来自专栏FreeBuf

国产指纹库平台 – 天蝎指纹库

前 言 信息收集为渗透测试环节一个非常重要的阶段,它关系到后序列策划攻击的成功性。快速收集目标服务信息则需要测试人员熟练运用指纹识别技术。 指纹识别概念 组...

48010
来自专栏星汉技术

计算机基础(三)

1416
来自专栏PHP实战技术

3-5年的PHPer常见的面试题

看到有很多,的总结一下,比较适合有一定经验的PHPer 平时喜欢哪些php书籍及博客?CSDN、虎嗅、猎云 js闭包是什么,原型链了不了解? for与forea...

43510
来自专栏腾讯技术工程官方号的专栏

大道至简—GO语言最佳实践

被称为GO语言之父的Rob Pike说,你是否同意GO语言,取决于你是认可少就是多,还是少就是少。

2.6K12
来自专栏Java成长之路

mo9 2年java面试总结

mo9是一家做数字货币交易所的公司,在4月份的时候自己去mo9参加了java开发的面试。mo9的面试更加注重基础,问了很多java基础方面的知识。下面将面试的一...

1042
来自专栏逍遥剑客的游戏开发

C#脚本实践(六): 脚本相对于C++的优势

5733

扫码关注云+社区