c++

c_c++技巧集.zip

作者：rick1126
email: [e-mail]
日期：2001-7-13 10:56:16
1.3 方法学介绍

    方法学时一组过程和启发式, 用以减少程序设计问题的复杂性

1.3.1 复杂性

     【程序设计指定原则对付复杂性】

       . 内部原则体现在程序自身的结构中, 机灵而有见解的程序员可以通过程序设计语言的表达方式了解这种内部原则		程序的本质
       . 外部原则体现在程序的源信息中, 一般被描述为"设计文档"(非产品文档)					程序的分析

       . 好的程序设计可以从外部原则上降低程序的结构方面的复杂性, 是程序成败的战略上的问题
       . 好的程序实现可以从内部原则上降低程序的代码方面的复杂性, 是程序成败的战术上的问题

1.3.2 内部原则

     【历史回顾 - 程序演化从处理内部原则开始】

       . 程序设计模型强加于内部开始, 标志性革命是为内存未知何机器指令指定别名
       . 命名子程序开始了面向过程的程序设计模型的历史

1.3.3 外部原则

     【程序设计的通常背景】

       . 设计本身 -- 如何使得程序工作, 并且如何使得程序易于维护
       . 开发人员 -- 不能假设开发小组是稳定的, 人员流动要求新老交替之时的交流 -- 文档就是形式之一

     【外部原则面临的问题】

       . 通讯 -- 交流问题
         - 好的方法( 外部原则 )应当是帮助人们进行思考和分析
         - 需要不断得到短期回报, 才能够激励小组不断进步; 这是除了逻辑因素以外的精神因素的考虑

       . 量级 -- 外部原则所占比重
         - 大型程序需要比较完善的外部原则, 因为问题比较复杂不是每一个新程序员都可以马上入手
         - 中小型程序根据需要部分的实现外部原则
         * 记住, 就商品角度而言, 外部原则不占客户所付金钱的份额; 但是对于软件企业则是一笔可以增值的财富
         * 软件公司乃至现在的一些公司除了物流( 生产资料 + 生产力 )管理以外, 其中在信息时代重要的一个特色就是信息管理
         * 信息管理很大一部分除了新的动态信息以外还有就是过去的一些静态信息的管理
         * 历史地看问题往往可以为预测和对应新的问题给出很好的借鉴, 辩证唯物主义也不仅仅是在意识形态上才可以体现价值

       . 问题层面
         - 项目设计往往分为3个层次 -- 问题空间, 解空间和机器空间
         - 外部原则往往有可能脱离机器空间给出通用的设计( 解空间 )
         
1.3.4 对象设计的五个阶段

     【设计过程】

       . 抽象 - 对象发现, 通过寻找外部因素与界线, 系统中的元素副本和最小概念单元得到
       . 继承 - 对象装配
       . 联系 - 系统构造, 建立各个类型之间的层次和关系
       . 改进 - 系统扩充
       . 复用 - 对象重用

       * 比照IDEF方法可见上述方法还是本着将问题逐步细化的原则. 区别在于IDEF是面向数据, 自顶而下, 相关的方法使用流程描述, 是一个非闭合环节; 而OOP则从显示世界出发从主要矛盾之中获得对象抽象类, 不但面向数据而且将相关的操作一起实现了封装, 而且对象之间的通讯也使用了消息方式, 因此更接近于自然的解决方案.

     【开发原则】
       
       . 将特殊问题归结为一个基类, 解决问题的过程就是类型成长的过程
       . 基本类型才是系统的主要内容
       . 解决问题的过程也是学习的过程
       . 在开发编程的时候可以实现模块方式的点到面的方式, 使用类的目的就是减少各个模块之间的耦合性, 增加聚合性; 只要接口保持稳定, 不当地实现方法可以使用新的方法完善乃至替代.
       . 接口的划分要求明确和简单, 复杂的问题可以使用组合等方式解决; 遵循由简到繁的逻辑原则, 否则无法将一个复杂的类型简单化

1.3.5 方法承诺什么

     【切记教条化】

       . 方法从概念触发仅仅是一些规则和启发, 提供更好的分析和思考的方式. 
       . 不能指望方法本身去解决问题
       . 不能死板的看待方法, 应当经验和实际情况相结合, 有发展的进行思考

     【方法的目标在于提高效率】

       . 解决问题, 不但是部分的也要考虑到对于全局的整体性影响

1.3.6 方法应当提供什么

     【基本功能】

       . 通讯约定
       . 支持项目结构化系统
       . 可以使用一些抽象的形式化工具进行描述 ( 比如: 文档, UML, IDEF的设计产物 )

     【通讯约定】

       . 敌对性环境		表示当事人互相之间存在认识上的差异乃至冲突, 使用约定可以规范各自的行为, 明确分工
       . 信息约定		表明意见一致的标准

     【系统结构化】

       . 系统的基本类型
       . 类型之间如何连接成为一个工作系统

     【描述工具 -- 符号原则】

       . 不包含不需要的东西, 否则不但容易引起误解, 同时也需要为此花费进行维护
       . 可以在较高的层次上创建一些必要时候展现的隐藏层次
       . 符号最小化
       . 类设计符号最小化, 如果该符号无助于表达OPP语言描述可以去掉
       . 内部实现的非重要性, 有时候内部实现往往是一种成规, 由于其往往和具体的计算机相关, 因此不能保证它不会妨碍到系统设计
       . 符号简单化

     【精神因素 -- 积极性】

       . 项目开发或者公司最为重要就是积极性
       . 管理技术不能够忽视在整个系统开发过程中的主体 -- 人的精神因素

     【不要犯经验主义的错误】

       . 相关书籍
         -- << 软件的创造力 >> ( Software Creativity, Robert Glass )
         -- << 人件 >>	 ( PeopleWare, Tom Demarco & Timothy Lister )
         -- << 复杂性 >>	 ( Complexity, M. Michell Waldrop )




〖个人理解〗

  这里主要讨论了一些高层次的方法问题和观念问题. 作为开发者, 对于先进的设计方法, 应该本着学习和实践的态度, 一旦将方法死板和教条化, 难免犯经验主义的错误, 毕竟方法仅仅是理论层面的事情, 解决问题还是需要实践. 我认为开发程序, 特别是新项目往往是犯错和学习的过程.

～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～