也谈面向对象的系统功能设计

之前在写我的程序人生的过程中，很多网友都希望我介绍一些编程开发方面的经验。我之前也说过，虽然我也算计算机专业科班出身，不过很多东西并不是在学校里从老师那里学来的，而是在工作中经过失败后总结出来的。至于总结出来的是不是最好的，最适合的，那就不知道了。我只知道在我目前的系统开发过程中，还是有一定作用的。本文我就想从系统功能设计方面简要介绍一下自己的一些思路和模式，也希望能够对大家起到抛砖引玉的作用。如果您有更好的方法，请务必留言赐教。

1。系统设计目标

封装性：高内聚，低耦合

对模块进行封装，便于重用，模块变化产生的影响范围最低。

可扩展性：考虑未来扩展的可能

函数，接口的设计，要考虑未来可能产生的扩展

一致性：包括模块设计的一致性，以及不同系统中同一模块的一致性

模块设计的一致性，要求各个模块采用一致的设计思路，简化设计的复制度，提高可读性和可维护性。

2。系统设计要点

追求完美，但不镀金

要有追求完美的心态，但却不能镀金，过犹不及。

注意80：20原则。争取用20%的成本实现80%的功能，而避免用大量的时间解决非重点问题或低概率问题。

换位思考，从用户角度考虑问题

特别对于界面的设计，包括图形和内容的显示。要以一个用户的角度来考虑。操作简单，界面美观，稳定高效等。

各尽其责

理解类和模块的意义，明确每个类和模块的责任和角色。不做不属于它的工作。一旦出现不应该由本类来完成的工作，那么意味着你的模块已经存在缺陷。

3。系统框架结构

具体每个部分的作用在以下的各个部分进行介绍。

4。MFC基础类职责

MFC基础类包括应用程序类，主框架类，视图类和文档类。

应用程序类负责系统初始化，包括检查配置文件信息的有效性，数据库是否能正确连接，系统是否注册等前端工作，以确定是否需要启动系统；

主框架类负责工具条，状态条，菜单和浮动窗体的管理，并作为整个工程中消息收发的中转站；

浮动窗体将作为一个容器，以TAB页的方式集成各个模块的信息展示和交互窗口，使得整个系统能有有效的窗口管理，不至于出现浮动窗口满天飞的现象。

视图类负责响应用户的鼠标和键盘事件，根据当前的操作状态将用户的动作投递给对应的实体模块管理类进行处理。并将结果在视图中进行绘制；

对于视图的作用，要记住一个原则，它只负责信息的交互，包括接收各种输入，以及相应的信息展示，不进行任何与业务相关的处理，所有业务相关的处理，都必须交由各个业务模块的管理类来完成。

文档类负责记录各个实体类对象的实例。

现在文档类的功能相对弱化，勉强负责业务模块对象的管理。

5。独立模块的组成结构

每个模块大致包括一个管理类，一个信息窗口类以及若干实体类。

管理类负责封装实体类对象与外界的交互，接收视图类传递来的鼠标键盘事件并进行调度；

从抽象层的角度来讲，管理类和视图类有些相似，它是在业务模块中的“视图类”，负责接收外界对模块的请求，并返回业务模块对外部请求的处理结果。

信息窗口类用于以数据或图形方式向用户展示实体类对象的信息，并接收用户的输入；

实体类表述具体的模块业务，可以根据需要分解成更多更具体的子模块。

信息窗口类和管理类为强关联关系，信息窗口类为管理类的友元类。管理类和信息窗口类都作为业务模块的辅助对象，原则上认为它们都是依赖于业务模块类而存在，因此，将两者作为一个整体。

6。消息机制

为了降低类之间的耦合度，类之间使用消息进行信息传递。

发往视图或者浮动窗体的消息，可以通过主框架类进行转发，这样可避免实体类和视图类以及浮动窗体类的强绑定。

为了避免在业务模块中直接引入当前工程的视图类等类对象，而导致业务模块和当前工程产生强关联的现象，所有业务模块的消息都发往主框架类，然后由主框架类负责转发给各个展示窗口，比如视图、浮动窗口等，它们都是由主框架类进行管理的。

为了支持某些特定的功能，系统增加类似的消息反射机制，视图发往具体模块类的鼠标事件如果该模块无具体的操作和变化，那么将把该事件通过消息发送给视图，以便可以进行默认的功能处理。

7。模块设计

一个模块可以分解为若干个物理类和逻辑类。物理类负责封装数据和对数据的直接的读写和处理方法；逻辑类负责管理和调度物理类。

物理类之上又可进行抽象，形成基类，充分利用面向对象的方法进行类的设计。

明确各个类的权利和义务，不做不属于它的工作。这一点可以和公司管理结构相对比来理解。

类的成员变量和方法，必须明确其属于公有，保护还是私有。成员变量应该提供方法封装读写操作。

以上基本上是作者多年来摸索出来的一套系统功能设计的模式，在作者一直以来的项目实践中得到应用。模块的迁移和替换代价都较低。由于所有模块有较好的一致性，新员工也能够对系统结构在更短的周期内得以掌握。当然，这只是一孔之见，还请大家多多给予意见。