写这篇文章,源于工作中自己的成长和一点一滴的总结。
因为这是心血来潮的第一篇,所以首先介绍一下开发背景,这里是以面向对象开发语言为主,当然不局限于 C++ 。
本文希望对于如下人群有所帮助:
1. 刚刚步入软件开发行业,并且热衷于面向对象编程的朋友
共勉!
为了阐述 C++ 例子,这里列举一个虚拟的设计模型, Ingor 公司开发了一个软件,软件的大体模块结构如下,然后在此基础上进行讨论和散发思维。
在仔细介绍上面的模块时,先介绍以后会一直用到的 Keyword 。
1 ) Graphic 为显示逻辑,以 View 的形式展现后台的数据
2 ) NetAccess 为网络操作,例如处理 Socket 连接等。
3 ) Report 为产生报表等
4 ) Cooperation 为合作模块等
5 ) Other ……无限衍生到各个领域的各个功能 / 模块,可谓包罗万象哦
针对上图分为四层:
1) 最上层,也就是客户拿到的 ingor.exe 。
2) UI 层,负责处理界面。从功能 / 模块上分为: UIGraphic , UINetAccess , UIReport , UICooperation 等等,各个模块分别处理相关逻辑的界面部分。比如 UIReport ,封装了所有关于产生 Report (报表 ) 的所有界面操作。 (Dll)
3) 逻辑层,负责逻辑处理。从功能 / 模块上分为: IGGraphic , IGNetAccess , IGReport, IGCooperation 等等,各个功能的逻辑处理相关逻辑。比如 IGReport ,封装了所有关于产生 Report (报表 ) 的逻辑。 (Dll)
4) 公共模块和数据层,封装了公共模块 (utility) 和数据模块 DataBase 和 DataContainer 。 DataBase 可以看成是数据库 , DataContainer 泛指针对任意存储介质的,可以是文件,内存等媒介 (Dll)
从上面可以看到 IGGraphic—UIGraphic; IGNetAccess----UINetAccess; IGReport---UINetAccess; IGCooperation----UICooperation; IGOther----UIOther ;之间一一对应,分别对应某一功能的逻辑和界面。
这样的一个模块结构,相信可以满足一般的以具体数据作为后台模型 的应用程序。下面抛出两个问题: 1 ) UI 层虽然功能相对比较独立,但是万一会出现某一个 UI 界面层需要另外一个 IG 逻辑层访问数据( UIReport 需要用到部分 IGNetAccess 中的方法等),应该怎么做呢?直接包含 IGNetAccess 中某些头文件吗, UIReport 依赖了 IGNetAccess 中的东西?新的需求来了,又要依赖其它逻辑模块,时间一长,发现原来的 UI 层和下层好几个逻辑模块互相依赖了。还有其它问题 , 等等。
2) 如果数据层不在本地,而是从服务器上获得,或者干脆目前的数据库( SQL )不能满足要求,要换成 Oracle 那么,怎样才能让上层的代码尽可能少的改动?
后续的文章将会给出该类问题的一些设计思路,并且还会抛出新的问题去思考问题。