| 面向概念 |
[Jul. 5th, 2009|03:33 pm] |
上次说"如果建立这样一个面向对象系统，其中不包含类的概念，只存在接口和对象，怎么样？"，是五月了，到现在 OOA 这本书还是没看完。刚才看到说“继承和聚合可以替代”，觉得不太对。如果一个地方只接受某个接口，那么聚合就必须暴露自己的成员。先前还说要封装，现在就丢掉了。如果从 OOA 的层次想，既然是“可以替代”，那么就没必要强调是哪种方式，而且继承、聚合和关联是蕴含关系。究竟分析的内容是什么？如果把被分析的内容称为概念，从常理推断，分析的内容和结果就是概念的定义和概念之间的关系。如果在 OOA 时注重的是概念而不是类，就更容易说清楚问题：毕竟提到类就会提到继承还是聚合，跟实现就有很大的关系了。写到这里突然想，类之间的关系只有继承和聚合，这个分析框架/语言可真是贫乏，不过考虑到分析的目标之一是与人沟通，词汇表和逻辑还是简单些好。那么全用概念来说不是更简化。从实现上说，一个概念对应的是一组属性和操作，也就是一个接口的实现。目前的实现中，一个类可以实现多个接口，也可能并没有将属性和操作定义为接口。但是在面向概念的表述中，属性和操作必须划分到概念里，也就是一个类至少需要提供一个概念，可以提供多个。如果这样定义类，它就成了一个集合。将集合和元素引入分析的过程，就让 OOA 更简单，不存在那么多领域相关的内容(除了软件设计，谁会这么纠结于继承还是聚合呢)。可是话说回来， OOA 毕竟是方法论…… 回到“概念”上，根据上面的分析，继承和聚合都意味着类拥有了多个概念。如果是写一篇论文，在大约2/3的部分应该想想这个东西怎么应用起来，比如写个软件，将现有的分析导入，转换为概念表示，再转出 OOD 适用的表示，其中就可以按照使用者的喜好，加上一点点常识，自动选择用继承还是聚合。现在的小程序员都没这个常识(比如我就很纠结用哪一个更好)，交给机器就不用烦恼了。代码翻译和自动重构也能用得上。刚才搜索 COP，发现了一个网站 http://conceptoriented.org/ 和上面这些不太一样，是跟 RPC 和控制流跳转相关的(是吗？)，觉得搜索关键字应该换个 AOP 试试。在天台上想到，如果列出最近关注的词会列出多少？
AOP: aspect
BOP: binding
COP: concept
DOP: data
EOP: engine
FOP: framework
GOP: generics
HOP: 我也不知道这个冷笑话可以说多少了。
...
OOP
Wikipedia: 范畴论 |
|
|
| 七月了 |
[Jul. 3rd, 2009|09:54 pm] |
每半年立一次志向，周转周期短一些，就显得比“一年之际在于春”更有效率。
做了半年的WPF，接触到不少以MS-PL方式开源的库，或者像CodeProject那样不讲究License的代码。虽然不是GNU/Linux的那种感觉，可是也算是一种约定俗成的生态。
今天学到了一些管理的常识，要关注同事，让他们能最好地发挥——正是管理三要素的第二项。至于“产出”和“社会责任”，还需要对号入座。
喜欢写博客的人们哪！千万不要迷上了所谓的“微博客”。写 140 字的文章来填坑，久而久之就挖不出坑了！
发现需要用半个月的时间读一本500页的书，持续三个月。 |
|
|
![[info]](http://l-stat.livejournal.com/img/userinfo.gif){kind=small}
joe_jiang's Friends Page