| 面向对象是一个挺让人迷惑的措辞.叫一切东西都是面向对象会让别人觉得你很时髦. Ruby 声称自己是面向对象的脚本语言;但究竟什么才是"面向对象"? 我们已经有了各种各样的答案,但所有这些恐怕都归结于同一件事.与其快速地概括它,不如让我们先花点儿时间考虑一下传统的编程模式. 传统意义上,一个编程问题从出现的各种数据,以及处理数据的过程(procedures)着手.在这一模式下,数据是呆板,被动和无用的;它完全的求助于那个体积庞大的,主动的,逻辑性的,全能的过程体. 这一做法的问题在于程序是由程序员写的,而他们仅仅能在工作中记下为数不多的细节.而随着工程的加大,它的核心也增长到难以记住整个工程是如何工作.细微的失误和敲打错误变得越来越容易造成难以发现的臭虫(bugs).繁杂和意外的干扰开始在核心内出现,维护也变得像企图抓住一只愤怒的乌贼还要不让它的触须碰到你脸.当然,对于传统方法,我们也有很多指导你去缩小和检测这些臭虫的方法,但更好的解决方法是彻底的改变我们的工作方式. 而面向对象所做的就是让我们将现实的,重复性的逻辑工作交给数据本身;它将我们对数据的概念从被动变为主动.换种说法:
上面所说的"机器"的内部可能相当简单或者复杂;我们不能从外面窥视,我们也不能允许自己打开机器外壳(除非我们确实发现其中有误),因此我们只需要通过拨动开关,读取刻度来操作数据.机器一旦建好,我们便不再必须考虑它是如何运转. 也许,你会觉得这是在无端的增加自己的工作量,但这一方法可以让我们有效避免事情向坏的方向发展. 让我们从一个简单的毫无实际价值却至少能说明部分概念的例子开始.你的汽车有个计程器.它的工作就是记录从上次复位以来的行车路 程.我们将如何用编程语言建模?在C里面,这个计程器也许就是个数值变量,大概是float类型的.这个程序会通过每隔一定的行程增加它的值,在合适的时候也会复位为零.哪里会出问题呢?程序里的一个臭虫会无端的向这个变量赋一个伪值,这可以由某些未预料到的原因而发生.任何有过C编程经验的人都会知道那会花掉数小时或数天来除掉这个当找出时简单得荒唐无比的臭虫.(找出它的那一刻往往会使劲地拍拍前额) 同样的问题在使用面向对象时会从一个截然不同的角度着手.当设计它时,程序员会问的头一件事不会是"什么是最类似它的数据类型?"而是"究竟这玩意儿是干什么的?"这不同之处引出了一个稍带难度的东西.我们需要花点儿时间确定到底计程器是用来干什么的,外部世界希望怎样操纵它.然后我们决定构造一个允许我们增加,复位,读值的小机器,再就没别的了. 我们并未提供一种用于向计程器赋任意值的方法:为什么?因为我们都知道计程器不是那样工作的.你只能向计程器做那定义好的几件事,而且是那些允许我们去做的事.因此,如果程序里的别的什么东西错误地向其赋值(比如,车的温度控制器),这立刻意味着错误的发生.当运行它的时候(或者当编译时,视语言的性质而定)我们便会被告之禁止向计程器这个对象赋任意值.给出的消息也许并非如此清楚,但它应该接近其真实原因.这并不防止错误的发生,是吧?但它很快给我们直接指出了问题所在.这只是OO编程会为我们节约很多时间的许多方法中的一个. 一般的,我们会考虑将上面的那玩意儿抽象化,因为建个工厂来造机器比一个个单独地造要简单的多.我们不希望直接的造单独的计程器; 换句话,我们希望所有的计程器都能由一个模型造出.这个模式(如果你喜欢,叫它计程器工厂)对应于我们所称的一个类,每一个由它生成的单独的计程器(或由工厂造出)对应于一个对象.许多面向对象的语言要求我们在拥有一个新的对象之前定义它的类,但Ruby不是如此. 当然运用面对对象语言并不意味着就会有好的面对对象设计.实际上,用任何语言都有写出模糊,粗心,多虫,低造诣及不稳定的代码.Ruby能为你做的(作为反例,特别是C++)是让OO编程的实践足够自然,即使你仅仅在小范围内使用也不会感到必须凭借丑陋的代码去提高效率.我们将会随着这本手册深入地讨论Ruby实现这些预定目标的机制;下一章将是"开关和刻度表"(对象方法),然后我们将讨论到"工厂"(类).你还会跟我们来吗? |
