解决问题的过程就是把问题(problem)划分为组件的过程

软件与人：
为了说明问题，我们先从人与计算机说起，计算机需要软件方才运行，软件是大脑思维的产物，因此我们可以得到这样一个结论：思维是程序运行的基础或者说，思维是软件的抽象，软件是思维的具体实现。

从编程语言说起：
编程语言开始于对机器的模仿，最初的编程语言带有机器的味道，比如对底层硬件抽象的汇编语言，明显的感觉到在操作机器，而不是在解决问题。这导致复杂问题解决的困难，因为编程语言都提供抽象机制，人们能解决问题的复杂度，取决于抽象的质量和类型，所谓抽象类型说的抽象的对象是什么，比如上面说的汇编，抽象的就是机器语言，也可以认为是对机器的直接抽象，之后的面向过程的编程语言比如c等，又是对汇编的抽象，抽象的程度越高，就越接近问题模型，所谓的问题模型是对问题的抽象。限制解决问题复杂度的关键在于，问题模型和语言抽象机制程度间的距离，也就是上面说到的---抽象的质量和类型。DSL(领域描述性语言)就是为了弥补这样的距离而产生的(实际上是限制问题模型的大小)，这类语言用于特定的工作，比如LISP和PROLOG主要用于人工自能，PHP，ASP主要用于web应用，然而DSL是有诸多限制的，很多人也不愿意为了满足某一特定环境而学习一门新的语言，而喜欢自己学习的语言无所不能。OOP(object oriented language)就是这样的语言，OOP提供一种更高层次的抽象(也就是：类)而又不至于使其变成DSL。万事万物都是对象，世界是对象的集合，对象有自己的状态，行为和标识，通过消息传递进行通讯。OOP解决问题的方式是，通过继承现有类或者新建类，产生适合问题模型的特定类。

必不可少的组件(component)：
复杂问题中，问题常常包含不只一个对象，甚至是成千上万个对象(成百个类)，它们关系复杂，作为一个开发者，永远无法看清楚每一个细节，著名的Miller法则这样描述： The Magical Number Seven, Plus or Minus Two: Some Limits on Our Capacity for Procession Information，它告诉我们，人同时处理信息的极限是7+-2个信息，这和人能跳高的极限一样，是无法改变的客观规律，因此我们应该很清楚的意识到，即使是OOP它如此高程度的抽象依然会远离问题模型，而导致复杂问题难以解决，为此引入component是必不可少的，component是这样定义的：component是一个定义了清晰的输入，输出和功能的单元，因此解决问题其实于对问题的拆分，把它拆分成为小于9个的组件，而后继续拆分这些组件，直到可以使用类来描述为止(类：对象的抽象)。组件三要素：名称(name，标识component)，功能(对特定component的定义)，接口(interface，用于发送接受消息)，这是符合组件的定义的。POSIX(X/Open的子集)可以说是最有力的证明组件化必要性的例子，它定义了所有函数的名称，接口和功能。

总结---软件开发：
意识到：软件即思维，思维即软件。解决问题的过程就是把问题(problem)划分为组件(component)，细分组件到子组件，最后到类(class)，按需要实现类，即对象(object，即实现)。整个过程中，仅仅是最后一步是具体的编码，而其他步骤都是“逻辑编码”，它的产物并非具体代码，而是一些思维的结果，由此我们可以理解，在解决问题的绝大多数时间里，我们都在思考。

假如你能理解本文会对构造一个易于维护的结构清晰的系统有一定帮助，同时对OOP有更深刻的理解。