举这样一个例子：假设我们要编写这样一个程序，需求是：输入圆形的半径，输出圆形的面积。
如果是面向过程的思想编程，他会这么想，输入数据：圆形半径，用double类型存储。输出数据：圆形的面积，也是用double类型变量存储。圆形面积的计算公式PI*R*R，这个就是算法，所以吻合我们编程界的名言程序=数据结构+算法。这里的数据结构很简单两个double类型数据，算法就是上面的计算公式。多perfect。
那么面向对象的思想又是如何考虑上面的需求呢？首先这里有三个关键名词圆形，半径，面积，两个动词输入和输出。所以他会建立一个圆形类，里面有两个属性：半径，和面积，然后至少有两个方法，1、给半径赋值的方法，2、计算圆形面积并且把计算结果返回的方法。多考虑一点话应该有带参数的构造方法重载，方便程序员在实例化圆形对象的时候就对半径做初始化赋值。这样就可以了吗？这个只是刚入门的oo程序员，这里也只体现了oo中的封装思想。更深入一点，我们应该考虑，这个需求在以后有没有可能扩充，比如求圆形的周长等。会不会还要求矩形的面积，如果以后有可能要计算矩形，三角形等形状的面积。我们是不是要对图形做抽象，抽象出Shape这个父类，这个父类是抽象类吗？还是用接口更合适。等等这就上升到了继承和多态的高度了。如果再往后考虑，求什么样的图形面积是项目部署的时候由客户动态决定的吗，那这里需不需要用到配置文件，需不需要用到设计模式，如工厂等。
可见面向对象的出现是为了应对越来越复杂多变的客户需求。在考虑问题的解决方案时，不在用以前解数学题的方式，不在首先考虑用什么样的数据结构来表示和存储需求中的数据，而是首先考虑如何划分功能模块。如何在模块与模块之间做成解耦合的效果等。看问题的角度更加的宏观。但并不是说面向对象和面向过程是对立的，在编程时基本单元如具体某个方法，它的编程方法依然是使用过程化思维的。就好像现在正在讨论中的面向方面编程，组件化编程等，它们的根基依然来源于我们的面向对象。
