什么是面向对象，怎么样以面向对象的思维来看待这个世界，分析问题？面向对象只是一种看待问题的方法而已，如果今后有比这更加有效的方法，那么新的方法就可以取代面向对象的方法。面向对象和面向过程的争议是没有意义的，因为它们不过是两种看待问题的不同方法而已，，哪一种方法更加有效取决于要解决的问题。在我看来，面向对象的方法可以更好的取代面向过程的方法。在这里我不会谈论面向过程的方法，因为每个人习惯性地用面向过程的方法来看待周遭的世界，而要以面向对象的方式看待问题，这个还真得花费一番功夫。就如同甲壳类动物要成长必须要蜕皮一样，以面向对象的方式看待问题，那么我们得重塑世界观。在物理学看来，一切物质从微观的角度看都是由原子构成。如果我们再把原子划分，就是原子核和围绕着原子核运动的电子，如果再细分呢，那么就是夸克了，夸克可能是人类已知的最小的事物了。实际上，在原子物理中，无论是核聚变还是核裂变，本质上都是质量的损失产生了能量，那么反过来，是不是其实所有的物质本质上讲就是能量呢。其实这个里面就包含了朴素的面向对象看待问题的世界观。使用面向对象方法来分析事物，实际上就是这么一个过程。所有事物都是对象，比如一辆汽车就是一个对象，这是从汽车这个层次来看的。往下一个层次呢，汽车由发动机、车轮等构成。也就是说，在同一个层次上，我们看到的不过是一个个蹦出来的对象，当然这些汽车的零件是按照一定的规则组成了汽车，我们可以将这个规则抽象出另一个对象。在工厂方法的设计模式中，这种思想体现的更为明显。那么问题出来了，一辆汽车该如何的设计呢？一辆汽车到底应该有几个轮子，几个方向盘，发动机该怎么装……这些问题就是软件学中的架构和设计，所以软件架构和软件设计就是这个样子。注意，软件的架构和设计和软件的过程管理不是一回事，本质来讲他们就不是同一个东西，但遗憾的是，很多人一提及软件工程就把这个搞模糊了。特别是某某大学出版的书，某某教授写的书，我很认真的告诉你，这些书，不要买，买了也是浪费钱，浪费时间，甚至把你带上歧途，他们最喜欢干的事情就是把某些他们自己都不理解的概念反复的绕，那些让你看上去很高深的东西其实就是废话。哪些书值得买呢，一定是那些长期在代码中浸泡，经过项目的洗礼的人才会有真才实学的东西教给你。但是有人说，中国的软件工程师，表达能力不行，把一些东西表达清楚，对他们来说太TM的不容易了，这个还真没办法。我在看很多的论文或者博客时，很多人把这些概念混为一谈。甚至我看到一篇硕士论文，开篇就这么一句“使用了UML设计方法”，UML是统一建模语言，如同英语一样，就是一门语言，难道有我使用英语设计方法这样的说法吗，我不知道这位硕士是如何能够毕业的，不过也不怪他，毕竟是学生，只能说他的导师SB，误人子弟。我很同意一种说法，这个世界的运转本质来讲，就是由人、事、物、规则构成。人要做事，那么人就是一个参与者，事就体现了这个过程，物就是这个过程中人使用的东西和产生的结果，规则控制着这个事。比如，我说，今天老爸去挖红薯了。那么整个描述就是就是一件事情，什么样的事情呢，老爸挖红薯了，这个事的参与者就是老爸，老爸使用的锄头和背篓、挖出的红薯，这些都是物，老爸挖红薯的方式，比如举锄头的方式，这些就是规则。规则控制整个过程是按照参与者的目的进行着。实际上在UML中，事就是用例。回到汽车的例子上来，我们知道汽车的零件能够组装出汽车。那么这些汽车的零件该如何被制造呢，这些汽车的零件的尺寸该如何定义呢，制造完这些零件我该如何组装呢？映射到软件生成的过程。一个用户说，我需要一辆汽车，你们这些软件工程师开始给我生产吧。合格的软件工程师首先会开始进行架构设计，把这辆汽车划分为轮子、发送机、车门等等模块。然后，找来负责生产发动机的工程师，对他说，你要设计这个发动机，这个发动机的尺寸是什么样子的，规格是什么样子的，螺丝是什么规格的。那么这个设计师就自己去设计了，只要交付最终的发动机是按照这个规格来的，那么肯定是可以组装到汽车上来的。同样的，找来负责生产轮胎的设计师，负责车门的设计师，等等。这帮设计师把该有的组件设计完成后，交给程序员，你们就按照这个设计生产吧。在这个过程中，就体现了架构师、设计师、程序员所处的角色。实际上，架构师的角色还没有更好的体现，比如用户说，我要能够在1s内加速到300公里的跑车，这个时候架构师就要很认真的考虑，这个汽车发动机该怎么选型，气动外形应该是什么样子的，这些不是普通的一个设计师能够干的，程序员更不可能胜任。对象该怎么抽象？如果你能回答这个问题，那么你是一个合格的程序员了。对象该如何更好的组装？如果你能很好的解决这个问题，那么你应该是一个优秀的设计师了。对于架构师，是从设计师慢慢的成长上去的。他需要掌握很多的东西，比如硬件，比如前端、后台、移动端。这些领域要精通熟悉，如果只是熟悉一个领域顶多是一个好的设计师。
妩媚动人，让我感受到了大自然的神奇。
