从项目始末谈面向对象——领域分析、需求分析、分析模型、设计、实现

从项目始末谈面向对象——领域分析、需求分析、分析模型、设计、实现

经过了六年的工作经验，有必要从实战的角度来谈面向对象设计。

因为经验派跟学院派的总结或多或少有些不同，也只有经历过，才知道血汗之辛苦。

“没经历过炮火的摧残，是不会知道战略、战术的实施智慧”。

以前从课本上、培训教材上看到的，一实际实践起来还是有很多的艰辛要体验。

毕竟没有实践经验的，多多少少有点纸上谈兵的毛病，对实际情况做了很多理想化的假设。

一个实际的项目往往受到三角制约：时间、工作量、进度。

因此，很多设计实际上必须经历权衡，而不是想当然的完美设计，

而且在实际上的设计由于系统本身的约束关系， 也必须在某些特性之间做权衡。

因此在设计过程中有时为了防止过度设计，可能会遵从一些简单的原则，这些原则可能要根据个人的品味去领悟了。

其实，我也领悟不是很深。

原则：

1）一致性：正交性（不要将独立的东西耦合起来）、妥适性(不要引入无形的东西)、普遍性(不要限制固有的东西)。

2）简单(KISS)：简化你的设计，不过从实际的工作经验来看要简化你的设计其实是很难的，需要你多层次的思考，才能达到简化。

也可以说简单是经历过后的境界，随便的简单，其实就是一种粗暴的行为。

3）三思而后行：想清楚你要做什么，避免返工，劳心劳力。

4）尽快建立原型：可以工作的程序，胜过完备的文档。

以下附上UNIX的设计哲学，觉得UNIX设计哲学从实践的角度来看，更有指导意义。

上面的一致性和简单性有时是有矛盾的，需要牺牲一方成就另一方。

这里引“简单之美——系统设计黄金法则”，对比学院派和实践派方法的不同。

1）MIT Approach

　　简单性：设计必须简单，这既是对实现的要求，也是对接口的要求。接口的简单要比实现的简单更加重要。

　　正确性：设计在任何值得注意的方面都要保证正确。不正确是绝对不允许的。

　　一致性：设计必须保持一致兼容。设计可以允许轻微少量的不简单和不完整，来避免不一致。一致性和正确性同等重要。

　　完整性：设计必须覆盖到实际应用的各种重要场景。所有可预料到的情况都必须覆盖到。简单性不能过度的损害完整性。

　2）New Jersey
Approach

　　简单性：设计必须简单，这既是对实现的要求，也是对接口的要求。实现的简单要比接口的简单更加重要。简单是设计中需要第一重视的因素。

　　正确性：设计在任何值得注意的方面都要求正确。为了简单性，正确性可以做轻微的让步。

　　一致性：设计不能过度不兼容一致。为了简单，一致性可以在某些方面做些牺牲，但与其允许设计中的这些处理不常见情况的部分去增加实现的复杂性和不一 致性，不如丢掉它们。

　　完整性：设计必须覆盖到实际应用的各种重要场景。所有可预料到的情况都应该覆盖到。为了保证其它几种特征的品质，完整性可以作出牺牲。事实上，一旦 简单性受到危害，完整性必须做出牺牲。一致性可以为实现的完整性作出牺牲；最不重要的是接口上的一致性。

　　如果觉得这种哲学描述太抽象的话，原文中有一个关于 Unix 中断处理的例子，非常生动。一位 MIT 的教授一直困恼于 Syscall 处理时间过长出现中断时如 何保护用户进程某些状态，从而让用户进程能继续执行。他问新泽西人，Unix 是怎么处理这个问题。新泽西人说，Unix 只支持大多数 Syscall 处理时间较短 的情况，如果时间太长出现中断 Syscall 不能完成，那就会返回一个错误码，让用户重新调用 Syscall。但
MIT 人不喜欢这个解决方案，因为这不是“正确的 做法”。

　　Unix/C开发于 1970 年前后，那时离 1964 年刚推出的 IBM System/360 没几年，软件刚摆脱硬件束缚，能移植到不同的机器上，从而变成了一种可单独 出售的产品。就是这样的一个软件产业的萌芽期，这种“实现简单”的理念被证明是更有效的。那么在今天的互联网时代，这种理念还有效吗？我们再来看下一 篇文章。
有兴趣的同学可以看：http://kb.cnblogs.com/page/143113/

废话了这么多，后继将介绍实际的工作体会，分享当时的设计体会。

不过，有些由于涉及到公司的信息安全问题，举的例子可能是LINUX里面的例子。