复制和粘帖是封装的大敌

所属分类: 网页制作 / 应用技巧 阅读数: 479
收藏 0 赞 0 分享
在侃侃而谈OO,侃侃而谈设计模式,侃侃而谈面向对象的诸多原则之前,我们首先应该掌握一点:封装。掌握好封装的原则和技巧之后,就算使用的不是OO语言,也能构造出框架优美的程序。将这些原则用在程序之外,也能得到出奇的效果。《设计规则-模块化的力量》(http://www.douban.com/subject/1737636/)将封装与模块化放在神坛的高位,它们配得上这个位置。这是我们解决复杂性问题的最基本的方法(没有之一)。

程序是一种复杂性系统。“道生一,一生二,二生三,三生(四,四生…)万物”。若将复杂性的根源当作“道”的化,那么这个“一”必然是封装。不同的程序语言以及由这些程序语言衍生的方法,则处于“二”的地位,比如 OO 设计范式、FP(函数编程)范式、分层的原则等等。OO设计准则,什么里氏替换原则,什么组合优先于继承,这些处于“三”的地位,具体的设计模式什么之类的处于“三”之后“四”的地位。

本人愚笨,至今尚记不清那些原则,如里氏替换原则是什么,那些这个模式那个模式怎么实现。设计模式中,俺只对策略模式感兴趣,对其它模式兴趣索然。实质上这些模式也好、准则也好,只是给我们提供了一种方法、一种工具去更好的实现封装。

复制和粘帖是封装的大敌,是丑陋代码的最大的坏味道。复制一份,就相当于增加了至少一个可变点,复制两份就相当于增加了至少两个可变点。为什么说“ 至少”呢,因为模块之间存在关联关系,导致一个地方的变化会导致其它的多个地方也必须随之变化。如果假定S为系统本身,M为对系统本身的一个测量,C为系统S中模块的平均复制份数(C>1),则这个M与C的关系应该是一个指数的关系: M正比于C的N次方(N>1)。

指数关系已经很可怕了,更可怕的是,当系统中的模块出现变化时,如果该模块在系统中有多个副本,我们可能偷懒,只改变了其中的一个副本,而不是全部副本都进行修改,这样就导致模块的分裂,由一个模块分裂成几个类似而又不同的模块,大大的增加系统的复杂度,最终导致系统的腐烂。直觉上,一个设计很烂的系统,它的复杂度大致是模块数量的阶乘关系甚至是幂指关系,这是比指数关系更恐怖的关系。

所以,复制和粘帖是一种非常邪恶的编码方式。在编码时,需要千方百计的去想办法减少复制和粘帖。这是在编码时就应该注意的问题,而不是放在重构阶段去做的事情。至于使用什么方法,使用什么手段,使用什么模式则是细节问题。

坚持不复制和粘帖,坚持下来,收益会非常大,写出来的代码质量高、含金量高。看见别人的系统,能马上分辨出这个系统的优点是什么,缺点是什么。什么设计模式也好,接口的正交性也好,设计原则也好,也许你从没刻意的去学过,却最终发现殊途同归,冥冥之中与国外大牛有一种心意相通的感觉。会自发的去组合、去改良这些大牛们的思想和方法,甚至去创造新方法新手段。直接由一入手,一生二,二生三生四,而非教条的、顶礼膜拜的去学这个三,学这个四。或许那个时候,你已经忘记什么是对象了。

之所以发这些牢骚,是因为昨天至今天,正在重构一个模块。这个模块M1的核心部件是一个包装自RTF的layout规则编辑器。设计这个核心部件的哥们以RichTextBox为中心设计了一个控件A,然后将这个控件的部分规则逻辑抽出来放在类B和类C的静态方法之中,更神奇的是这个类B是在另一个模块M2之中,类C倒是在模块M1之中。这个控件在M1中被三个地方给用到:D、E、F,这D、E、F每个地方都要为这个空间A注册七八个事件,然后在事件的回调函数中调用模块M2中的类B的静态方法及模块M1中的类C的静态方法去实现一些逻辑。现在呢,我要写一个控件G,这个G也要用到控件A,在这种情况下,我必需为G注册一堆A的事件及回调函数,然后在回调函数中弄一堆逻辑,至少得200行代码。为了写这些回调函数,我必须得搞清这个A控件及类B,类 C的内部运行机制。也就是说,为了吃猪肉必须得亲自去杀猪。当然,也可以从D、E或F 中Copy代码过来改吧改吧来节省时间。

问题严重的地方在于,这个控件A本身存在逻辑错误,存在功能不完善的地方,需要对它动手术。因为到处复制,牵一发而动全身,给A动手术必须也要给 B、C、D、E、F五个类动手术。在给A动手术时,为了编译通过,我将B、C、D、E、F中与A相关的代码全给注释掉了,前后注释了1500行代码左右。实质上这1500行代码真正有价值的代码也就在200行左右,其它的代码全是复制、粘帖,然后改改变量名完成的。

为什么会出现这样的问题呢?因为复制和粘帖。复制和粘帖省事啊,Copy过去改几个词就能用了,不用花费心思的去想封装。而实际情况是,要引用那个控件A,得写200-300行代码,多引用几处,就得写1000多行代码,复制和粘帖的话倒不费事,但如果发现这个A存在错误,或者需要扩展,在改A的同时,同时也要动这1000多行代码,这1000多行代码中可能会牵扯到更多的代码,最终导致必须修改更多的代码,这便是代码的腐烂。

其实这个A是很好封装的,它不需要其它的类对它输入任何输入数据,其它的类只需要从A控件中获得一个最终的规则结果,一个List。封装的好的话,调用A,获得结果,两三句代码就可以实现。

之所以不封装是因为习惯了复制和粘帖,或者懒于去封装,或者头脑中根本没封装这根弦。

很多新程序员或者不新的程序员,尤其是Web开发程序员老抱怨工作的技术含量低,老是想学更多的东西。实质上,他们所作的工作是非常有技术含量的东西,就看怎么看待。

如果只将自己的工作看作简单的复制、粘帖、抄袭、改代码的话,自然技术含量低了。如果将自己的工作看作如何消除复制和粘帖、如何提高质量、进度,消除工作中的不必要事情,消除各种浪费,那么这个工作的技术含量是极其高的。不要膜拜大师,当你这么做的时候,你做的正是大师的工作。不要膜拜新技术,当你这么做的时候,你的工作可能正是新新一代技术的萌芽。一点一滴、一色一香,全在心中。青青翠竹、尽是法身,郁郁黄花、无非般若。
更多精彩内容其他人还在看

32个典型的以分栏/网格为基础的网站

如果你正在寻找网页分栏设计的灵感,这里收集了32个典型的以分栏/网格为基础的网站。它们显示了在网页设计中分栏/网格的重要性,无论对于信息量巨大的站点还是个人博客。 1.The New York Times 2.National Post 3.Guardian 4.Times
收藏 0 赞 0 分享

理论普及——用户体验

一、概念分析1:UE用户体验 英文叫做user experience,缩写为UE, 或者UX。 当指电子商务网站的时候也被称作顾客体验(CUSTOMER EXPERIENCE). 它是指用户访问一个网站或者使用一个产品时的全部体验。他们的印象和感觉,是否成功,是否享
收藏 0 赞 0 分享

分页案例和好的实践

结构和层次降低了复杂性并提高了可读性。你的文章或站点组织的越深入,用户就越容易理解你观点和得到你想传达的信息。在网页上,这点被通过多个方式做到。 在正文头条和列举被用做逻辑上独立的数据块来呈现信息。另一种解决方法是一种叫分页的机制,它在给定文章的单一部
收藏 0 赞 0 分享

建立用户体验

也许你刚刚来到一家公司,他们希望进行一些“可用性”工作。你可能是一名UI设计师,业务分析师,或前端开发人员,一名产品经理,或者负责用户体验部门的经理或副总。你知道,如果更好地了解使用产品/软件/网站的人,就可能开发出更好的产品/软件/网站。不管怎么样
收藏 0 赞 0 分享

网页图片快速显示的方法和技巧

1. Use .gifs rather than .jpgs. GIFs are smaller in size when compared to JPGs. 1.用.gifs格式保存图片,最好不要用.jpgs格式。因为前者的尺寸比后者小。 2.Use 'Height
收藏 0 赞 0 分享

推荐60种分页案例和好的实践

结构和层次降低了复杂性并提高了可读性。你的文章或站点组织的越深入,用户就越容易理解你观点和得到你想传达的信息。在网页上,这点被通过多个方式做到。 在正文头条和列举被用做逻辑上独立的数据块来呈现信息。另一种解决方法是一种叫分页的机制,它在给定文章的单一部
收藏 0 赞 0 分享

全面的网站评估方案

有时会被问到“看看XXX网站如何?”之类的问题。 谈到评估,通常都是指产品级的网站,如果模式很新,了解需要花一定时间。于是,很多人又问“那么你仅从UI/UE的角度看看呢?”首先我们得达成共识,一切花里胡哨都在为功能服务,如果功
收藏 0 赞 0 分享

网页的栅格设计思考

原文地址:http://andymao.com/andy/post/82.html 网页设计中的脏、乱、差,是我们在设计过程中常会遇到的问题。通常"脏"是由对色彩使用不当所产生的,而色彩使用不当产生的不好效果也分为:"花、灰",花哨、
收藏 0 赞 0 分享

设计理论设计中的层次感

原文:http://andymao.com/andy/post/80.html 这段时间我一直在说设计需要有层次感,这种层次感可能有很多类型,比如色彩的层次感,或是元素的层次感。当一个设计缺乏层次感的时候页面所表现出来的无非是两种可能,一种是单调,一种是花哨。在设计中我们常
收藏 0 赞 0 分享

网页心得:网页色彩的搭配

网页的色彩是树立网站形象的关键之一,色彩搭配却是网友们感到头疼的问题。网页的背景,文字,图标,边框,超链接...,应该采用什么样的色彩,应该搭配什么色彩才能最好的表达出预想的内涵呢?这里谈一些心得,希望对你有所启发。 首先我们先来了解一些色彩的基本知识:
收藏 0 赞 0 分享
查看更多