Spring带来了什么？OOD学而无用

这有点绝对了。

有时候ood是为了改进设计。
曾经 用解释器模式帮助改造 一个过程方式写的日志解析代码。
效率提高好多好像最少50%，还方便增加新的日志格式解析。

当然，原来那个过程设计问题蛮大的。

本文的OOD是指UP中定义的OOD。也就是软件工程意义上的OOD。OOD是软件开发过程中的一个阶段，使用OOD会产生OOD工件：比如：顺序图、类图。OOD是有前题的，需要先进行OOA。

在OOD中应用设计模式，是产生良好OOD结果的重要手段。但设计模式本身并不是OOD，它并不能揭示OOA和OOD的关系，而这是OOD的出发点。就是说如何从OOA导出OOD结果的。设计模式是不会告诉你这个的。

采用OOD后。软件中会出现领域层，这带来两个好处：

1.业务逻缉集中在领域对象中实现，并和现实世界具有对应关系，因此易于理解和演进。
2.业务逻缉以OO的方式实现，必然带来细粒度的接口划分，设计模式的应用，这会消除业务逻缉的重复代码，带来重用，提高可读性。

这是为什么充血模型适合复杂业务逻缉的原因。

如果 用这种僵化的思维去解释 OO 难怪会有 明明用着 Java这种 面向对象的语言却反对OO的人。

能够使用设计模式 解决问题，当然首先 要把问题 映射到 OO的结构上，也就是 OOA，然后才能应用
设计模式 OOD。
不是说 一定要画个组件图，组件内再画类图， 然后才写代码，还要求组件间一定要用接口，才算是OOD。

btw 良好有五分 应该是我投的   

呵呵，那多谢你吧。

我也不想扣字眼，这没有意义。但是OOD有它本来的含义。

不如把OOD分开。以我目前的认识，可以分为三个层面：

1.软件开发过程中的一个特定阶段。在这个阶段作什么工作，以什么作为输入，产生什么输出，是明确的。
2.软件表达业务逻缉的方法。即采用充血模型，让分析和设计采用一致的形式。
3.具体设计问题的解决方案：设计模式。


在spring环境下，前两点目前都只在理论层面，第三点，目前偶有应用。

在过去一年，我参与的spring web项目，一个设计模式也没用到。

投五分 不是代表 赞同观点，只是觉得这种讨论能带来一点不一样的思路。

观点和纯理论的讨论 有时也是必要的。

web项目难以应用OO，spring不是直接原因，是Web方式的本身问题。

很久以前参加过一个SUN的JavaONE的会议，Web container是被归到表现层的，本身就很薄。

没有spring之前，各种框架，比如struts1，也难以用DDD方式编程。

BTW，现在有个MVP模式的说法， 其实Struts 1/2， Spring MVC都是这种。

对具体的业务来讲，最终还是要归到 一个完整的流程，只有业务的众多流程 有其共性的时候，才可以用OO来帮助简化。不用重复写相同代码（相同不是相似，如果把相似都干掉，时间人力成本有可能反而增加。） 把共性抽取出来，写入框架，那么剩下的就还是要手工做的事情。

比如，我以前公司，就写了一套框架，把表格界面做成一个通用性的组件，可以通过定义列，来自动生成查询语句，和表现层，里面就用了很多OO的设计。
到最后我们的工作就是调整定义和写后台的数据库存储过程……

最后还是回到我的理解，OO本质还是分解问题，隔离问题，解决问题。
OO不一定能在实际工作中有直接帮助，但是可以帮助程序员理解框架，从更大范围来理解系统，视角不仅仅局限于小模块编码。

1.在spring中设计模式已经被用到了....
不写java代码就不是设计的想法本身就是错误的
写xml也算是模式,
约定配置也是模式

2.OOD设计 是指在设计过程中 对现实的仿真
基本上我见过的设计比如ERP,商城
很少不用OOD进行设计
当然OA这边有点特别.....现实开发方式模拟,不如工作流更科学,方便

3.充不充血是实现方式,
与使用SQL或NOSQL一样,
对面向对象这个概念不冲突,
更像对象也不是我们要追求的目标

4.我们都是站在巨人肩膀上的开发者
如果我说购物车,仓库,警戒线,盘库,
大家都知道我在说什么
但这些东西在系统中有时不是这么实现的
我接触过的一个项目
只有库单表
仓库的警戒线是入库总数-出库总数 < 本类产品的设定警戒线
而且这个算法是在盘库时触发的.

这种需求很特别
但是对于开发来说一点也不难理解

对于入库唯一编号作用进行了隐藏
对于盘库发现失盗处理过程排除系统之外

嗯嗯,就是这个意思.设计和技术选择,及编码实现是分开的.

要从整体来看,设计这个功能能做什么,涉及其他什么模块,应该如何去做.这才是第一步.

但无可奈何人的思维是跳跃和联想的.看见某个功能,会根据习惯,不由自主的会想到技术、框架、编码、数据库结构.思维定势了.程序员更多想的是,如何实现,需要多久,这两个问题.囧.

有些公司也会有 Domain 设计的职位,有点类似项目经理,产品策略的一些工作.
他们不会该关心 Spring 或是 hbm ,(虽然这个职位很多是技术出身的)

谈了这么久，到底什么是OO 啊？
任何编程语言都是有其数学基础的，比如从图灵机和post 机基础上发展来的命令式语言，从lambda 演算发展出来的函数式语言，以及从霍恩子句发展出来的逻辑编程语言。逐步发展甚至混合形成现在各式各样的语言。
但是OO 呢？一直有人努力，但现在从未有人能成功的给出其数学基础，离其最近的数学理论也只不过是PI演算。
所以说，OO 不是一个什么必须遵从的天则，它只不过是我们编程中的一个最佳实践，就有如设计模式一样。那么OOA 与OOD 也只不过属于软件分析设计的方法论中的一种而已。
在java 这种静态类型语言中，OO 这种最佳实践给我们带来的两个好处：
1、数据结构化，并且可以基于简单的结构，我们可以方便的构建出越来越复杂的结构化数据，就好像java bean 一样。
2、范围限制，其实就是所谓的封装。一个get() 函数，在不同的类（也可以说namespace）中有不同的表现，互不干扰。其实，想想以前的c 就明白这样做有多大的益处了。

在java 中，我们总是说OO，但是实际上，我们到底是面向Object，还是面向Class？
我们只能define 了class 后，再实例化一个object 出来。我们所有的设计只能针对class。
这种方式，就如柏拉图的理型世界的理论一样，只要现实世界一复杂，这个模型就变得非常脆弱。

对于你说的第2点和第3点。有些需要确认。在不同的公司中，软件术语的不一致会导致根本无法交流。我的确遇到过这样的情况。

1.你说的OOD设计：是不是将系统作为一个黑盒，对其所在的领域进行分析。分析包括两部份：一部份针对行为的；另一部份是针对概念的。

前者常使用用例进行表达。后者者分析的结果通常会表达为领域模型、分析模型、或概念模型，对应的是UML中的类图。

如果你说的OOD的内含是我说的以上内容。那在我这里则称之为OOA。

本文的主题没有说OOA无用，因为OOA中的分析方法，也是我常用的。

2.对于第3点。你讨论的是实现上的问题了。需求和实现间的关系的确如你所说，并没有人说OOA的结果必须采用面向对象的方式来编写（OOA的结果是对问题域的形式化描述，和代码无关）。但软件逻缉的表达的确可以按两种方式组织(就是你说的实现方式)：一种是面向过程的；一种是面向对象的。我说的OOD是用来支持产生面向对象方式逻缉表达的软件设计方法。

基于以上两点。我和你确认一下。你所说的“对现实的仿真”应该是和代码无关的活动，目的是形成对现实世界的正确理解。对于我来说这是OOA，你说的仿真，对我来说就是需求分析阶段的建模活动。

如果我理解有误，能不能举一个具体的访真例子？这样我能更准确的把握你说的内容

OO -> OOP --> OOD --> OOA

好吧为了能确定咱们划一个大概边界来区分
我们的软件开发一般分几个阶段
1.需求调研  成果物: 需求报告 ,DEMO,界面原型
2.设计      成果物: 概要设计 ,详细设计,测试用例
3.开发      成果物: 代码 ,布置完成的项目,
4.测试      成果物: buglist ,设计变更协议书,项目验收报告
5.运维      成果物: 资源使用率,全年停机时间,扩展性 曲线.

我认为
1.作为A的周期
2.作为D的周期
3.作为P的周期

举个例子
1.一个url是否可以被访问
应该如何设计呢?

spring的文档中最精彩的一个词叫
投票

这个词隐藏了一些复杂的逻辑判断过程
你把这些逻辑判断过程写成设计文档时
很难一次明白,不过这也让不了解投票这个词的人一头雾水
所以权限模块使用了投票这个与权限一点逻辑关系都没有的设计