2010年10月09日 12:06 "SpeedVan"的内容

严格来说，操作系统和数据库也是应用，跟应用软件开发遵守同样的规律 ...


操作系统无论严不严格来过都应该不是应用软件，可能以前系统（非操作系统）带有部分应用，而且当时应用软件并不广泛，而让人误解而已。何为操作系统，应该不用我 ...


数据库和操作系统服务于应用，相当于它的需求是许许多多应用提出来的，或者说是总结出来的。在这个意义上，数据库和操作系统也是应用。
应用软件服务于一般人，数据库和OS服务于程序员、同时也服务于一般人（OS中的很多人性化功能是为一般人开发的，而不是为程序员）
数据库和OS的开发过程必定也是设计为主，算法和数据结构之类只能居于次要地位，而且数据库和OS非常复杂，其对设计（而不是算法）的能力要求更高。

从开发角度看，OS一样要需求分析，一样要设计一个好的、有弹性的架构，一样是“设计优先”，而不是算法优先，更不是算法堆砌。

[该贴被cxz7531于2010-10-09 13:37修改过]


2010年10月08日 10:46 "flyzb"的言论
模式是解决某类业务过程场景的经验套路，而OO是分析业务过程的设计思想 ...


前者略认同，后者不敢认同，对我的认识，OO是只是一种思维，并没有具体到设计上面，因为并没有说“OO设计”的，只有“OO程序设计”，“OO软件设计”，OO只是思维，与设计无关。

为什么说前者略认同，我理解模式是一种从解决项目的经验中提出出来的抽象认知，对“经验套路”这个词略不同意（你的整体意思感觉是对的），经验套路是可以各自一方（也就是一间公司一套经验套路），但模式应该是这些大家套路中再次抽象出来的认知。以上个人理解而已，若错望指正。

To SpeedVan
从用户的角度看，业务就是面向过程的，同时相互关联的，根本就没有什么OO和模块之类的东西。为了支撑用户的业务，我们需要用OO的思想去分析设计，所以我说“OO设计”。从软件功能实现的角度看，“OO”是一种思想，而设计要落到具体的技术上。所以“OO是设计还是思想是相对而言的”。
关于模式是一种“经验套路”的问题，其中的“经验”就不用说了，大家都赞同。而“模式套路”的说法，是指不能用套路的方法来使用模式，而你看到的听到的关于模式的东西都是以一种套路的形式表达出来的。

尽管跑题了，但还是感谢 cxz7531 和 flyzb 的热心回复（如何真有必要讨论，请立新帖，这里只是告诉新手们软件开发的基础已经不再是算法和数据结构了），但我在这里也作出回应：

TO cxz7531
可能你还需看看操作系统和应用软件的定义，或者是他们划分的目的，这两者划分是从软件的目的划分的：系统解决交互，应用软件解决应用领域问题。至于你说他们存在架构，项目开发技术等支持，那是因为过去的应用软件写过程模式已经不能满足需求，所以要加入项目思想，架构是为了快速开发，而以前这些是不存在的。

当前应用软件当中包括了一般应用软件和应用系统，应用系统就是我们经常讨论的对象，它不是操作系统，因为它解决了一个领域的应用（一般应用软件则是解决某方面的应用，但还是面向应用的，尽管它没有系统式开发）。操作系统的面向方向和应用软件有着质的不同，他只是单单解决交互，而这也是对它的定义。

TO flyzb
我所表达的是OO思想是不能用来分析和设计的，他没有指导一个东西应如何去分析，如何去设计，它相当于一种表达方式而已，相当于语言（JAVA），只是语言（JAVA）是一种具体表现形式（语句，代码），OO只是一种抽象表现形式（思维），但他们并没有任何分析与设计的。例如四色原型指导分析，DDD领域设计指导设计，而设计模式只是帮助设计的实现，他们都必须以OO思维为基础。若果OO没有了这些分析思想和设计思想（哪怕只是个人总结出来的），OO就不能支持分析和设计了。简单说就像世界观和方法论。

至于套路，我理解是实际行动的抽象（必须绑定在某一事务上），抽象思想的实现（是一种具体的思想）。如武功上所说的套路，它必须是某套武功的套路，一个套路是对某武功而言的，套路不可能是全部武功的。而设计模式则是类似武功套路的再一次升华，可能好像“后发制人”这些词语吧，而这些如何表现在某武功的套路上，就像设计模式如何表现在JAVA的特点和技巧上。设计模式是离开具体语言的，也就是我不把它理解为套路的原因。一种极端而且不准确的描述，但有助于理解：设计模式里面的XX模式就只是一个词而已，至于它到底表达什么样的技巧，就得在具体语言上表达，于是就出现了套路。嘛，其实就是对套路这个词的理解，我知道我们的思想是同一个的。
[该贴被SpeedVan于2010-10-10 14:54修改过]
[该贴被SpeedVan于2010-10-10 15:01修改过]
[该贴被SpeedVan于2010-10-10 15:02修改过]

2010年10月10日 14:54 "SpeedVan"的内容
可能你还需看看操作系统和应用软件的定义，或者是他们划分的目的，这两者划分是从软件的目的划分的：系统解决交互，应用软件解决应用领域问题。至于你说他们存在架构，项目开发技术等支持，那是因为过去的应用软件写过程模式已经不能满足需求，所以要加入项目 ...

我并非不知操作系统和应用软件的差别，当然按主流划分，操作系统不属应用软件。
我所强调的是：
1 不管应用软件和操作系统，开发过程都是设计架构优先，算法居次要地位。那种认为算法好就可以去开发OS的人，是可笑的，如果他真去设计OS，肯定会发现，OS有着比应用软件还要复杂得多的架构，对弹性化设计的要求更高，单单是设计系统API就需要很强的业务分析能力。
2 应用软件和操作系统都是商业软件，都要符合用户的需求，服务于特定的人群。从这个意义上说，操作系统也是应用。都遵循需求分析、架构设计、建模等等一系列过程，还有严格的过程管理。

我的理解，这两块本来就是一个软件系统里处于不同层面的东西，直接拿来做比对时不合适的人，要把他们对立起来就更是关公战秦琼了。设计模式的偏重于应用层面，是在更上层以战略角度进行分析设计，算法，数据结构式底层的战术实现。
上层设计到位了，下面的算法可能非常烂，但是还是能满足大部分业务需求，顶多是性能不佳，而自底向上分析，过分重视算法，数据结构这些东西，搭建出来的东西可能在非功能性需求上做的不错，但是不一定能满足用户基本需求。
总之，没必要非要争出哪个第一哪个第二来。

只能说各有侧重。
搞底层的侧重算法，搞应用的侧重OO。
等你功力够深厚的时候，会悟出2者其实是相通的。

一个人对付一群人，我笑了

看着别人低复用性、低伸缩性、低可读性的代码，我也笑了~一个人？我从不认为我是一个人，呵呵

上页