你有没有很困惑？“很多人在没有规则时不知道怎么做事，有规则时又不遵守规则行事”。或许人就是这样，其实道理都很简单，简单到每个人都通晓，甚至于讲起来个个口若悬河，但是你总能发现那些违背道理的行为发生，于我们编码领域这种情况或许更甚。我们抛开写出令人惊叹的编码这种理想不提，因为怎么看都觉得很假，其实我自己也觉得很假。那么至少让我们编码取悦自己。
基于此对复制、命名、面向对象编码这三个至基本，甚至让人觉得太简单的事上，以提问的方式，权当对自己粗鄙想法的一个梳理，记录以示警醒，至少让编码自己看着不那么不堪。
一、你真的懂复制吗？
圈里大牛曾说过“懒惰是编码工作者一个优秀的品质”，以这种逻辑，“复制”绝对是一件值得赞扬的行为，毕竟我们的使命就是消减重复劳动，提高生产效率嘛。让人欣慰的是我们每个人都懂复制如何操作，但是你真的懂“复制”吗？简单粗暴的拿来主义是“复制”的全部吗？
至少我不这么认为，“复制”是有前提的，是基于对被复制内容的理解的。了解了被复制内容中的每一行代码之意图，为什么要这么写？能产生怎样的效果？如果我删掉其中一行又有什么影响？更好的情况是进一步对被复制内容提出自己的评价，它里面有没有错误？是不是有更好的方式来实现同样的效果？或是仅能增强代码可读性，使编码更优雅的写法？为什么毛泽东是伟人，他不是因为把社会主义从苏联复制过来就成为伟人的，他是复制过来改造成中国特色社会主义才成为伟人的。
有了这些前提，“复制”才可以执行，而不是不管不问，盲目搬移，这样不仅整体来看不能提高效率，反而会带来许多问题，进而降低效率甚至导致项目失败。比如，随着复制可能带来了无效代码，增加维护人员梳理时间，降低代码可读性。更糟的情况是带来了错误漏洞，引入潜在风险，直接威胁系统运行。
而常常发生的，是很多人在复制的时候连那些系统特有的标识符号都不做改变，你会莫名其妙的发现一个根本不属于当前功能的标签突兀的出现。举最常见的数据展示表格为例，通常我们会给每个数据表格加一个标题，以描述当前数据，如“学生成绩表”“学生档案表”，由于都是表格展示，他们展示形式的编码都是一样的，在实现了“学生成绩表”之后，我们可以复制代码来完成“学生档案表”的展示，但是完成之后你会发现系统中有两个标题“学生成绩表”，仔细看看数据才发现一个是档案表。我们常将抄别人作业不改名字的行为当笑话来讲，可我们的行动却进行着抄作业不改名字的实践。
任何时候，都不要使用自己无法驾驭的东西，相信我，后果是灾难性的。
二、名字重要吗？
每个人的人生中都会经历命名这件事，我们还想给每一座山每一条河起个温暖的名字呢。那为什么要有名字？仅为了标识吗？如果仅是标识，那123abc也能做到啊，为什么还要费神费力为每一个类、属性、方法定名字呢？
名字除了标识之外更重要的是解释说明被标识的内容。从这种层面讲，大师讲的“如果名字命的好，就不需要写太多注释了”是有道理的（当然有可能名字命的不好你也不写注释，那请出门左转，记得带上门），如果为一段代码写了大段注释，那就该想想是不是名字命的不太贴切呢？
从词性上讲，通常类、属性都是名词为佳，方法以动词更好，因为它描述的是行为。
大师还说过一句话，“请尽量避免缩写”。尤其那种自创的缩写，请告诉我有几个人看到“SI”能马上明白是Student Information的？使用缩写的原则是在某个领域约定俗成的，公认的，大家一看就明白的。譬如互联网行业的O2O，SKU，SEO，软件行业的CRM,ERP等。除此之外，请不要偷懒，把单词写全了真不费事，如果单词不会用拼音（全拼）也比自创缩写好。以现今的存储能力真的可以忽略长名字对内存的影响，所以不要顾虑占空间。
请记住，你的编码首先是给人看的，其次才是给机器读的。通常系统的后续维护成本要远高于开发成本，而良好的编码风格可以节省维护成本。这算是一种职业操守，请在编码时保有一个良好的编码道德，做个好人。所以名字很重要。
三、面向对象到底是什么？
不知从哪一刻起，面向对象被迅速发扬光大，门下徒众遍布。几乎每个人都在讲面向对象，你一定听过“万物皆对象”的口号。但回头看看你的编码吧，它真的面向对象了吗？请认真回答你在写下一个类，完成一个方法，增加一个属性的时候真的有考虑面向对象吗？
我只想你认真回答这两个问题，至于面向对象的定义、特征和优点，我想你一定倒背如流，所以只需要去看看自己的编码，诚恳面对自己就好。
人总是这样，说的和做的之间总差着一个懒惰的距离。
最后，我想谈谈个人对面向对象中封装性的理解。封装是面向对象的基石，没有了封装根本不会存在面向对象这种概念。那么封装是什么？
封装被定义为“隐藏对象的属性和实现细节，对外公开接口，控制在程序中属性的读和修改的访问级别，将抽象得到的数据和行为相结合，形成一个有机的整体”。这个定义中阐述了三个关键点：第一，隐藏实现细节。第二，控制访问级别。第三，结合数据和行为。
关于第一点，大多数情况下有高级开发工具的加成，我们都会定义出带有getter、setter，属性全用private修饰的类，然而这并不是全部，你只是隐藏了属性，关键的实现细节呢？你隐藏了吗？仍以学生为例，简化后假设学生有“名称”，“成绩”两个属性，学生的名称是有来历的，借助一些规则产生，比如暗合生辰八字。学生的成绩也不是随便画的，是学生自己经过努力学习（也或者是抄同学）挣来的，所以学生有两个方法“生成名称”和“获得成绩”。属性“名称”和“成绩”是私有的，如果方法“生成名称”和“获得成绩”是公开的，那不叫真的封装，毕竟谁也不想把自己抄同学这件事公诸于众吧，至于生辰八字，更是关乎命运的隐私，岂敢儿戏。所以，请一定关注实现细节的隐藏，真的很重要。
至于第二点，编码中最多的除了private就是public，但其实访问控制修饰符还有两个的protected和default，请不要冷落它们，都是一个娘生的，既然有就用呗，“资源不利用就是一种浪费”（忘了谁说的）。所以在计划公开信息时，能给尽量少的人看就别让多余的人看了，信息很贵的，再说这世界坏人那么多。
第三点，行为要和数据结合，不要拆散它们。“宁毁十座庙不拆一桩婚”啊，老话是有道理的。为叙述方便这里不严谨的从狭义角度暂且认为类之属性即为数据，所以操作属性的方法要跟着属性，即属性在哪里，操作它的方法就应该放在哪里。那么，我们的问题就退化为属性应该在哪里的问题。其实也很简单，属性是谁的就该放在谁那里。学号是学生的，那学号就应该只放在学生类中定义，语文是课目的，那就让它待在课目类里。当然，你说我把语文放在学生类里也能实现功能，没错，我相信你能，但是也请你出门左转，记得带上门。其实这种道理大家也都懂，但是就为着书写方便，我们为一个类附加了太多本不属于它的东西，甚至不惜在实体类里塞入集合来收纳杂七杂八的东西。接着上文例子，语文放在学生类里，后来学校增了数学课目，所以学生得对自身进行修正才能继续上学，可是关学生自身什么事？遇上气性大的，闹个罢课游行什么的，学还办不办了？如果实体类里除了自身特性还有集合，那就是提醒你重新考虑设计的警告，请不要无视它们，放它们回家，世界才会更和谐！
我们追求自由，厌恶规则，可是规则是自由之母啊，有规则就去遵守，在规则里你会获得真正的自由。多想想，其实编码很可爱的，乐趣横生，它一定能取悦你！
网友评论