面向对象的C++设计杂记

任何对本文的引用,请指明出处。

 

本文是面向对象的C++设计方面的一个杂记。我会一天写一点直至完成。

1.类设计的CheckList

koenig有篇关于类设计的checklist的文章非常好,我摘抄这个list如下:

  1. 私有数据。如果不想将特有的数据暴露给外部,请使用函数来让外界访问私有数据;
  2. 构造函数。如果类对象需要特殊的处理来完成对象内部功能的建造,就需要考虑构造函数;
  3. 缺省构造函数。如果该类对象不需要显示初始化,就需要缺省构造函数;
  4. 所有构造函数需要初始化所有数据成员吗?
  5. 需要复制构造函数吗?如果构造函数内分配了资源,请考虑复制构造函数
  6. 析构函数。如果类分配了资源,请在析构函数内释放
  7. 类需要虚拟析构函数吗?如果需要继承的子类对象有多态的对象删除就需要虚拟析构函数
  8. 需要赋值运算符吗?如果存在复制构造函数,多半需要赋值运算符
  9. 赋值运算符考虑自身赋值了吗?
  10. 需要定义关系运算符吗?如果想创建类的有序集合,则需要定义关系运算符
  11. 删除数组时调用delete[]了吗?
  12. 复制和赋值构造函数参数加const了吗?
  13. 如果函数有引用参数,它们应该是const引用吗?
  14. 成员函数是const吗?

2.面向对象的软件设计感想

软件设计需要丰富的经验和对问题域深入的了解,这是一个重要的先决条件。我见过许多所谓的软件设计人员,甚至号称为架构师的高级设计人员,对问题域都没有做深入的了解就进行所谓的软件设计,甚至指导真正的开发人员进行开发。荒谬到了极点,最终的软件让人啼笑皆非。其中充斥着不合时宜的所谓的模块,无法适应新的需求,开发人员天天就忙于fix bugs。我很是纳闷,如此差劲的所谓的设计人员安排都拿着高昂的薪水,冠着“设计师”的光环,竟然在许多组织中大行其道,而没有在管理上采取必要的措施......,可悲!!!

我从事软件开发好多年了,见过许多优美的设计,也见过许多象垃圾一样的东西。对于一个事物是否优美,不同的人审美观念不同,答案也不同。有的人喜欢华丽辉煌,有的人喜欢简洁朴素。我本人喜欢后者,一个复杂的问题,被简单干净痛快地解决掉,还有比这更漂亮的设计吗?所以这其中有一个设计哲学和理念的问题。我推崇“简洁”,软件领域我相信超过80%的人和我一样。但是“简洁”不意味着“简单”、“粗糙”、“原始”,我总结了几点优美的设计必备的要素:

1)概念清晰简洁。所有模块及功能是单纯和清晰的,角色是明确的

2)对象关系层次清晰明了。

3)多一分则多,少一分则少。恰到好处的拿捏是很技术的

4)灵活。能灵活地适应变化

5)关键的一点设计不能偏离一个中心:需求。设计得再优美,如果偏离了需求,就象缘木求鱼又有什么意义呢?

我看到过许多所谓的架构师对第5)点缺乏根本的把握,“唯美”的设计如果脱离了现实的环境和实际的运用,又有什么存在的必要呐?

 

3.设计模式学习的几个阶段

设计模式已经流行多年了,模式概念的兴起是软件行业设计和开发的一大进步。模式将常见的问题的解决方法程式化,同时在广大开发人员中形成一种共同的语言。现在简直成了检查一个软件工程师水准的一种方法和手段。观察周边的同道对模式的认识上大致有如下的几个阶段:

  1. 初级阶段。只知道几个模式的名字,生搬硬套地使用。一碰到问题不能一下就正确地选定合适的模式,正确地处理细节。
  2. 中级阶段。熟悉各个模式的应用范围和背景,能区分应用的场合,正确地使用。能够适当的对模式进行裁剪和扩充
  3. 高级阶段。无招胜有招的出神入化阶段。同时积累了大量的自有模式,对特定行业常用模式有丰富的经验和把握。

 

 

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值