
要说学习面向对象难不难?实话告诉你,以前我觉得难得要死。那些书里写的什么“抽象”、“封装”、“多态”……每一个词都像是从火星蹦出来的,看一遍头就大一圈,合上书我就忘光了...
要说学习面向对象难不难?实话告诉你,以前我觉得难得要死。那些书里写的什么“抽象”、“封装”、“多态”……每一个词都像是从火星蹦出来的,看一遍头就大一圈,合上书我就忘光了。
我当时那段经历,现在想起来还心有余悸。我在老家一个小公司做了两年,当时我们的项目就是用最原始的函数堆起来的。功能一多,代码文件就跟一盘意大利面一样,
盘根错节,你根本分不清哪根是哪根。
有一次,一个核心功能出了个恶性Bug,用户一操作就闪退。我的老大让我赶紧去解决。我接过代码文件,光是看那几千行连在一起的函数,我的汗就下来了。我花了两天,像个没头的苍蝇一样在里面
钻来钻去,到处找
那个变量到底是在哪儿被改坏的。第三天早上,我顶着俩黑眼圈,终于找到了那个错误——原来是一个最底层的小函数,被上层十几个不同的大函数
随便调用
,导致它的状态乱七八糟。我当时就崩溃了,改了这里,那边又爆了

盯着
我,那眼神简直能把我穿透。那天晚上我回到家,气得把键盘都快
砸了
。我就问自己:难道写代码就必须是这个样子吗?必须是这种互相拖后腿、一坨屎山

翻出
了以前买的编程书,翻到
了面向对象那一章,我决定
了,这回我不要再去背
概念,我要动手搞
清楚,这玩意儿到底是怎么回事。我给自己
定了个规矩
,从那一天开始,我把书本扔到一边
,只盯着
现实世界的东西来学习。我总结出
了三个最管用的小技巧,让我彻底摆脱了
对OOP的恐惧。我1
找
了一个最简单的东西——我的电动车。我不再去想
教科书里的“类”是什么,我只看
这个对象本身。画下
了我的电动车。列出
它有哪些东西:车轮、车灯、电瓶、车座。这些就是它的“属性”。写下
它能做哪些事情:启动、刹车、鸣笛。这些就是它的“行为”。我
意识到
,面向对象,就是把相关的东西都圈在一起
,取个名字叫“车”。这样下次我再提到“车灯”,我就知道
它属于“车”这个整体,不会再跑出去
跟别的代码搞混
了。这一下就解决了
我代码里变量到处乱飞的问题。我
尝试
给我的邻居设计
一辆摩托车。摩托车也有车轮,也有车灯。难道我需要把
“车轮”和“车灯”的代码再写一遍
吗?太蠢了
!我
想
了个好办法,我做
一个最原始的“交通工具”模型,里面只有
车轮和刹车这些基本功能。然后我让
我的电动车和邻居的摩托车,直接从
“交通工具”那里把它们“借”过来
。这就是“继承”。我
发现
,我的代码量一下子少了很多
。我只需要在每个具体车型里,加上
它们自己特有的功能就行了(比如电动车的“电量显示”)。我不再用
复制粘贴大法,避免了
重复劳动,感觉
瞬间高级了很多。这个
解决
了我之前最头疼
的那个Bug问题。以前我的底层函数谁都能动
,所以它很容易就被弄坏
。现在我
用“封装”来解决
:把
电动车的内部电路和发动机都“藏”到
一个盒子里。不给
外面的人看
里面的细节。只提供
一个清晰的“启动”按钮
,你只管按
就行了,不用管
里面的线是怎么接通的。这意味着外部的代码
想直接改动
我的核心属性是不可能
的。它只能通过
我提供的“按钮”来操作。这样我的底层代码就安全得多了
。然后我
学会了
“多态”。以前我要写一堆
`如果它是电动车就执行A,如果是摩托车就执行B`的判断。现在我直接告诉
它“跑起来!”就行了。摩托车知道
自己要烧油跑,电动车知道
自己要用电跑。它自己会决定
用哪种方式。这一下子就干掉
了我项目里最烦人
的条件判断代码块!我
用
这三个小技巧,动手把
我那个出问题的项目重新架构了一遍
。我创建了
“用户”、“订单”、“支付”等几个核心对象
,然后让
所有相关的功能都归属
到它们下面。代码变得极其清晰
。你现在
问
我学习面向对象难不难?我的回答是:一点都不难
。你只需要放慢脚步
,别被那些高大上的名词给吓唬住
了,抓着
你身边最普通的一个东西开始拆解
就行。从实践中走一遍
,你会发现,它不过就是一种更聪明、更整齐
的方式来管理
你那些乱七八糟
的代码而已。现在我的代码再也没有出现过那种全线崩溃的情况。 老大
再也没用那种眼神看过我
。我感觉
我的职业生涯,真的是从那次动手实践
之后,才算真正开始走上正轨
的。