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