13,190
社区成员
发帖
与我相关
我的任务
分享新写了一篇文章：泛谈OOAD（面向对象分析设计）回答了上次的一些问题
请大家到我的博客阅读，欢迎留言指正。
我的博客：http://blog.csdn.net/aafshzj
这篇文章：http://blog.csdn.net/aafshzj/archive/2006/09/29/1306917.aspx
我的博客：http://blog.csdn.net/aafshzj
这篇文章：http://blog.csdn.net/aafshzj/archive/2006/09/29/1306917.aspx
...全文
请发表友善的回复…
发表回复
yggpc 2006-10-24
- 打赏
- 举报
ding
aafshzj 2006-10-13
- 打赏
- 举报
不能沉
aafshzj 2006-09-29
- 打赏
- 举报
最近有点闲散，很久没有写文章了。明天起要认真准备一点东西，一段时间内也没什么时间动笔。看了一些朋友的留言和回复，觉得还是有必要抓紧时间将一些思路写出来与大家分享。
AAF系列还将写下去，但是AAF的一些具体实现确实是比较枯燥的。所以本篇文章同前一篇类似，还是以谈思路为主。这次我们谈一谈OOA和OOD。我不准备去按教科书的讲法介绍二者。教科书中的东西有时候象是筋被挑去的动物解剖尸体——清晰、冷酷、完整但是也没有呼吸。当然，这并不是说基本概念不重要，基本概念非常重要，但是基本概念的重要并不在于你需要将一段段文字背得滚瓜烂熟，而在于深刻的理解。理解的过程实际上是你通过反复的实践，对知识在头脑中不断建模和修订的过程。
那么怎样的理解可以说是深刻的理解呢？简而言之，那就是你对每一个知识点（方法、定理...）的适用条件、裁剪依据，相互关系、具体内容、利弊之处等都有了尽可能清晰而在你的个人经验中找得到实际支撑的认识，不再不知何时该使用，不知如何使用，也不再为了使用而使用。如果你读了一本书，这本书中所提到的各种概念所依托的事实，你以前大多没有在实际操作中接触过，短期内你也不会在具体任务（工作任务或者自己定的任务）中用到它。那我觉得你这本书基本读得没什么意义。这也就是我常说：“你用不着的东西就不要去学，如果学了就要赶紧找机会去用”。人的知识体系的生长过程其实极其类似晶体的生长过程：新的知识是围绕着旧的知识建立起来的，旧的晶体如果还没长结实，或者根本没有相关的旧知识，或者就的知识和新的知识没有找到一致的生长方向，那么，轻轻一哆嗦，堆砌起来的新的知识就会洒落一地。只有不断学习、不断实践，围绕学习实践、围绕时间学习，晶体才能按照内在的纹理和晶格方向最健康的生长，完整的晶体也才有可能形成。
可惜的是，我们的教育体系，基本上大学四年都是在让学生稀里糊涂地泡在哪里，晶体稀里糊涂的乱长者，失去了在实践中的反复推敲和反馈调整。稀稀拉拉的分子结构到了毕业就业的时候根本不成形状。问起来什么似乎都知道一点，用起来却根本不成系统。这怪不得学生，但也怪不得不喜欢应届生的企事业单位，要怪的是教育体系。
扯得远了，按照惯例，还是把我关于OOAD的一些认识列举出来：
1）OOA的实质是确定问题：系统的边界和部分细节（交互细节，而非全部细节）。
OOA的实质就是确定问题本身，此时此刻，应把系统看成一个黑盒，所有的工作都围绕确定系统边界这一点展开。一个常见的误解是觉得分析不应涉及细节（很多时候大家说“实现细节”，但很多人其实是把细节都算作实现细节的）？然而事实恰恰相反，分析并不是不涉及细节，虽然也不是涉及所有细节。分析的目的就是要确定和系统边界有关的所有细节——我们称之为交互细节。那么什么算是交互细节呢？交互细节就是系统与外部交互的所有细节。这包括：a）有哪些交互，b）分别是和谁（外部系统）交互，c）这些交互的具体过程和逻辑是怎样的，d）对这些具体过程和逻辑有什么其它（分别或者总体）要求？
在这些要求里a），b）一般不难甄别的，c）一般是关键所在，而d）则往往从属于c）。在对c）进行深入讨论之前，我们要注意到一件事情，那就是在考虑b）的时候，我们有时候（不是所有的时候）必须把需要选用的技术平台作为需要与目标系统交互的外部系统来看待。因为很多时候或者是我们自己，或者是我们的用户会对技术平台的选用提出非常具体的要求。当然，对于这部分外部系统，我们可以不必考虑其与系统的交互，因为这些系统一般都提供了对我们来说几近常识一般的API，我们所要做的只是在分析中标注这些API就够了。
下面我们来看“c）这些交互的具体过程和逻辑是怎样的”。如何回答这一问题呢？让我们以UI（UI本质上和API没什么太大区别，可以把UI看作基于人工智能+视觉/多媒体调用的API，也可以把API看作形式化、简单化并通过内存地址调用的的UI）为例来考虑这一问题。当我们在考虑UI中的一个交互时，我们需要非常细节化、非常明确地回答下述所有问题：
i）交互的名称
ii）交互的前提条件
iii）交互中传入什么数据，传出什么数据，具体内容、格式及内容的内在关系。
iv）交互的逻辑（包括何时传入或传出上述数据）及分支
v）外部系统在交互中的各个节点希望达到的实际效果或结果
vi）其它外部系统关注或者必须提交的信息。
实际上我们看到，我们这里提到的一切几乎都和UML中的概念存在着对应关系，如：
外部系统（包括各种用户）->Actor
交互->Use Case
交互->Use Case
交互的具体过程和逻辑->用例描述
...
对于有一定OOA经验的人来说，这可能有点老生常谈了。但是重要的是实效和执行：如何运用上述基本原则正确、完整、一致、无歧义、清晰地描述系统的需求，永远是一个挑战。
如果说OOA的基本问题是确定系统边界的话，OOD的基本问题就是如何对我们手中的工具（如.NET的各种类）进行组合，建立符合约定边界特征的系统。
2）OOD的实质是把责任横向分解或者说横向聚合。
既是分解又是聚合，这确实是个充满哲学气息的命题。
.......
AAF系列还将写下去，但是AAF的一些具体实现确实是比较枯燥的。所以本篇文章同前一篇类似，还是以谈思路为主。这次我们谈一谈OOA和OOD。我不准备去按教科书的讲法介绍二者。教科书中的东西有时候象是筋被挑去的动物解剖尸体——清晰、冷酷、完整但是也没有呼吸。当然，这并不是说基本概念不重要，基本概念非常重要，但是基本概念的重要并不在于你需要将一段段文字背得滚瓜烂熟，而在于深刻的理解。理解的过程实际上是你通过反复的实践，对知识在头脑中不断建模和修订的过程。
那么怎样的理解可以说是深刻的理解呢？简而言之，那就是你对每一个知识点（方法、定理...）的适用条件、裁剪依据，相互关系、具体内容、利弊之处等都有了尽可能清晰而在你的个人经验中找得到实际支撑的认识，不再不知何时该使用，不知如何使用，也不再为了使用而使用。如果你读了一本书，这本书中所提到的各种概念所依托的事实，你以前大多没有在实际操作中接触过，短期内你也不会在具体任务（工作任务或者自己定的任务）中用到它。那我觉得你这本书基本读得没什么意义。这也就是我常说：“你用不着的东西就不要去学，如果学了就要赶紧找机会去用”。人的知识体系的生长过程其实极其类似晶体的生长过程：新的知识是围绕着旧的知识建立起来的，旧的晶体如果还没长结实，或者根本没有相关的旧知识，或者就的知识和新的知识没有找到一致的生长方向，那么，轻轻一哆嗦，堆砌起来的新的知识就会洒落一地。只有不断学习、不断实践，围绕学习实践、围绕时间学习，晶体才能按照内在的纹理和晶格方向最健康的生长，完整的晶体也才有可能形成。
可惜的是，我们的教育体系，基本上大学四年都是在让学生稀里糊涂地泡在哪里，晶体稀里糊涂的乱长者，失去了在实践中的反复推敲和反馈调整。稀稀拉拉的分子结构到了毕业就业的时候根本不成形状。问起来什么似乎都知道一点，用起来却根本不成系统。这怪不得学生，但也怪不得不喜欢应届生的企事业单位，要怪的是教育体系。
扯得远了，按照惯例，还是把我关于OOAD的一些认识列举出来：
1）OOA的实质是确定问题：系统的边界和部分细节（交互细节，而非全部细节）。
OOA的实质就是确定问题本身，此时此刻，应把系统看成一个黑盒，所有的工作都围绕确定系统边界这一点展开。一个常见的误解是觉得分析不应涉及细节（很多时候大家说“实现细节”，但很多人其实是把细节都算作实现细节的）？然而事实恰恰相反，分析并不是不涉及细节，虽然也不是涉及所有细节。分析的目的就是要确定和系统边界有关的所有细节——我们称之为交互细节。那么什么算是交互细节呢？交互细节就是系统与外部交互的所有细节。这包括：a）有哪些交互，b）分别是和谁（外部系统）交互，c）这些交互的具体过程和逻辑是怎样的，d）对这些具体过程和逻辑有什么其它（分别或者总体）要求？
在这些要求里a），b）一般不难甄别的，c）一般是关键所在，而d）则往往从属于c）。在对c）进行深入讨论之前，我们要注意到一件事情，那就是在考虑b）的时候，我们有时候（不是所有的时候）必须把需要选用的技术平台作为需要与目标系统交互的外部系统来看待。因为很多时候或者是我们自己，或者是我们的用户会对技术平台的选用提出非常具体的要求。当然，对于这部分外部系统，我们可以不必考虑其与系统的交互，因为这些系统一般都提供了对我们来说几近常识一般的API，我们所要做的只是在分析中标注这些API就够了。
下面我们来看“c）这些交互的具体过程和逻辑是怎样的”。如何回答这一问题呢？让我们以UI（UI本质上和API没什么太大区别，可以把UI看作基于人工智能+视觉/多媒体调用的API，也可以把API看作形式化、简单化并通过内存地址调用的的UI）为例来考虑这一问题。当我们在考虑UI中的一个交互时，我们需要非常细节化、非常明确地回答下述所有问题：
i）交互的名称
ii）交互的前提条件
iii）交互中传入什么数据，传出什么数据，具体内容、格式及内容的内在关系。
iv）交互的逻辑（包括何时传入或传出上述数据）及分支
v）外部系统在交互中的各个节点希望达到的实际效果或结果
vi）其它外部系统关注或者必须提交的信息。
实际上我们看到，我们这里提到的一切几乎都和UML中的概念存在着对应关系，如：
外部系统（包括各种用户）->Actor
交互->Use Case
交互->Use Case
交互的具体过程和逻辑->用例描述
...
对于有一定OOA经验的人来说，这可能有点老生常谈了。但是重要的是实效和执行：如何运用上述基本原则正确、完整、一致、无歧义、清晰地描述系统的需求，永远是一个挑战。
如果说OOA的基本问题是确定系统边界的话，OOD的基本问题就是如何对我们手中的工具（如.NET的各种类）进行组合，建立符合约定边界特征的系统。
2）OOD的实质是把责任横向分解或者说横向聚合。
既是分解又是聚合，这确实是个充满哲学气息的命题。
.......
