很多时候，我们理解面向对象是就方法加上数据，封装就是隐藏数据，但这并不全面。好比说，猫有一个脑袋、四条腿，一个尾巴一样，虽然没有错，但并不全面。从外表上来看，面向对象的确是这样，但其本质在哪里呢？让我们来看看《Design Patterns Explained》，它告诉我们一些什么。
功能分解 vs. 需求变化
在面向对象之前，我们采用的开发方法是面向过程，而面向过程开发中最常用的一个分析方法是：功能分解。我们会把从客户那里得到的需求分解成模块，然后把模块分解成大的功能，然后把大的功能分解成小功能，最终分解成一个一个的函数。这样做非常容易，但是会产生一个问题：面向过程中的控制程序（一般是主程序）承担了太多的责任。
控制程序什么都要管，就好像有的家庭过于溺爱孩子，孩子一切一切家长都包了，这样的孩子出去以后，往往受不得半点委屈，调节能力很差。采用面向过程开发的程序往往也是这样，它们过于脆弱，不能够应对需求变化。
责任分解 vs. 功能分解
既然面向过程不能很好的应对变化，那面向对象和它的不同之处在哪里？答案就是——责任分解(shift of responsibility)。责任分解其实很简单，就是自己的事情自己做，自己对自己负责，就像家长不必事事都帮孩子做，指导一下，然后让他们自己去做，这样往往效果更好，家长也轻松的多。
面向对象把一系列相同责任的方法和数据放在一个类里面，封装起来，这样内聚性提高了，从代码角度上说，减少了很多重复。另外，面向对象还把这些相似的类抽象起来，做成抽象类或接口，进一步减少重复代码。在对象之间相互调用的时候，往往依赖于抽象类和接口，这样，代码之间的耦合性大大降低了。一句话,面向对象的天生适合增加内聚性，减少耦合性，减少重复代码，这样便能更好的应对需求变化
总结
功能分解 vs. 需求变化
在面向对象之前，我们采用的开发方法是面向过程，而面向过程开发中最常用的一个分析方法是：功能分解。我们会把从客户那里得到的需求分解成模块，然后把模块分解成大的功能，然后把大的功能分解成小功能，最终分解成一个一个的函数。这样做非常容易，但是会产生一个问题：面向过程中的控制程序（一般是主程序）承担了太多的责任。
控制程序什么都要管，就好像有的家庭过于溺爱孩子，孩子一切一切家长都包了，这样的孩子出去以后，往往受不得半点委屈，调节能力很差。采用面向过程开发的程序往往也是这样，它们过于脆弱，不能够应对需求变化。
责任分解 vs. 功能分解
既然面向过程不能很好的应对变化，那面向对象和它的不同之处在哪里？答案就是——责任分解(shift of responsibility)。责任分解其实很简单，就是自己的事情自己做，自己对自己负责，就像家长不必事事都帮孩子做，指导一下，然后让他们自己去做，这样往往效果更好，家长也轻松的多。
面向对象把一系列相同责任的方法和数据放在一个类里面，封装起来，这样内聚性提高了，从代码角度上说，减少了很多重复。另外，面向对象还把这些相似的类抽象起来，做成抽象类或接口，进一步减少重复代码。在对象之间相互调用的时候，往往依赖于抽象类和接口，这样，代码之间的耦合性大大降低了。一句话,面向对象的天生适合增加内聚性，减少耦合性，减少重复代码，这样便能更好的应对需求变化
总结
面向对象的关键在于责任分解。接口、继承、封装不光是为了隐藏数据，更重要的是隐藏类型，是松散耦合。