前提：

类：

变量：

变量的名字：名字应该要能完整、准确地描述变量所代表的含义。

变量的作用域：作用域是指变量的有效范围，我们也可以简单的认为是变量使用之间的行数。

方法：

方法的名字：好名字非常重要

方法参数：最理想的参数数量是零，最多不要超过3。

类：

类的长度：第一原则是短小，第二原则还应该更短小

类的命名

类的成员变量：

良好的封装：

类与类（设计原则）

开闭原则

依赖反转

前提：

这一年，有幸参与了一项用户较多的项目，所以在写代码的思考如何使代码更少的侵入，更低的耦合，如何写出更好的代码易于他人理解等等。于是，读了很多关于如何写代码的书籍，在这里重新整理，总结对自己在实际开发中影响较多的地方。

类：

变量：

变量的名字：名字应该要能完整、准确地描述变量所代表的含义。

思考：这一项很简单，但是变量的名字往往与代码的可读性相关。代码阅读的次数远远大于编写的次数，所以我们在写代码时，要更侧重阅读而非编写。变量合适准确的名字可以更有利于阅读代码，并且在使用变量的时候可以避免错误。

例如：对于循环索引而言，如果一个变量要在循环外使用，或者循环是一个较大的函数，应当使用非ijk的命名

对于临时变量而言，temp不能完整表示其含义，应当使用真实含义的单词。

避免使用具有相似含义的名字，避免拼错单词。

变量的作用域：作用域是指变量的有效范围，我们也可以简单的认为是变量使用之间的行数。

思考：对于作用域，我的理解是这里尽量不要让变量的使用范围过大。当作用域过大，依旧是可能引发错误。我们的注意力最多只有一屏甚至不到，变量的作用域过大，难免会错误的赋值错误的引用等等。所以，减少变量的作用域可以降低错误的可能性。

例如：在循环开始之前再去初始化循环里要使用的变量；直到变量即将被使用的时候再为其赋值；把使用变量相关的语句放到一起，提炼为单独的方法；一个变量在使用前采取最严格的可见性然后随着使用的需要逐步扩展。

方法：

方法的名字：好名字非常重要

思考：我们很多时候会说方法行数不能太长啊，方法要有内聚性啊，方法要让人容易看懂啊等等，但这个往往在考虑方法的名字的时候就可以确定了。比如当我们想要明确的表达一个方法的名字的时候，却发现这个方法包含两个或两个以上的动作的时候，我们无法用一个词语准确的抽象这个方法在做什么，那就应当考虑这个方法内聚性是否不好，是否不是只做一件事，需要拆成两个以上的方法了。

所以，方法名字要描述所做的所有事情，避免使用无意义、模糊或表述不清的动词，对返回值要有所描述，命名含义要清晰易懂。往往我们在确定方法名字的时候，就可以约束方法。

方法的长度：第一原则是短小，第二原则还是短小

思考：以前我们常说什么长度不要超过一屏，后来才了解到这个说法是在上世纪80年代形成的，当时的显示器完全不像现在能呈现这么大的视野，因此现在的一屏已经是太长太长太长了。我们要坚持确保一个方法只做一件事，去保障功能上的内聚性。

方法参数：最理想的参数数量是零，最多不要超过3。

思考：方法的参数往往也决定了方法的内聚性和方法的长度。过多的参数和不好确定的方法名一样，都要考虑这个方法是否违背了方法只做一件事的原则。严格意义上，方法参数出现布尔值就要思考这个方法是不是做了两件事？

我们还会遇到很多方法由于修改，造成有的方法参数不再使用，应该及时的删除，保证使用方法所有的参数。更不要将方法的参数直接用作工作变量，当需要对参数进行计算等操作时候，请使用局部变量。

类：

类的长度：第一原则是短小，第二原则还应该更短小

思考：对于方法我们计算代码行数衡量大小，而对于类我们使用职责来衡量。单一职责SRP，使我们创建类使用类应该遵循的，类应该有且只有一条加以修改的理由。

类的命名

思考：对于类的名称而言，应当直接可以看出其职责。命名对于类而言，也是帮助判断类的长度的第一个手段。如果我们无法对一个类以精准的名称，那就说明这个类太长了。同时，一个类的命名越模糊，比如processor，manager等，该类包含的职责可能越多，往往最后发散成一个庞大杂乱的类。

类的成员变量：

思考：类的成员变量使用是否过于奢侈？每一个成员变量是否对于类的每一个方法都需要使用？成员变量的增多往往会让类的内聚性降低。通常而言，一个方法使用的成员变量越多，那这个方法就更黏聚在这个类上，就拥有更大的内聚性。

良好的封装：

尽可能限制类和成员的可访问性
不要公开暴露成员数据
不要对类的使用者做出任何假设
留意过于紧密的耦合关系
让阅读代码比编写代码更方便

思考：不要对类的使用者做出任何假设这一条，我们在很多大型项目里总是会看到注释告诉你应该怎么使用。但是这个注释使用者是否会看到，而且这个注释是毫无约束性的，所以我们在编写代码的时候要充分考虑清楚如何限定你的代码如何使用，最好的注释应当是代码。

类与类（设计原则）

思考：SOLID原则主要是告诉我们如何将数据和函数组织成为类，以及如何将这些类链接起来成为程序。但我们总是去想着怎么利用设计原则来写代码，思考用什么设计模式，但设计原则应该是思想，是遇到问题解决问题的思路。当没有问题的时候不要强上设计模式，否则很容易造成为了设计模式而设计模式，最终成为过度设计。这里，我只总结两大容易搞错的原则。

一般情况下，我们为软件构建中层结构的主要目的为：

使软件可容忍被改动（开闭原则）
使软件更容易被理解（单一职责）
构建可在多个软件系统中可复用的组件（里式替换）

开闭原则

先说开闭原则，是因为开闭原则其实是一种思想，如何实现开闭原则的方法，往往是设计原则其余方案的体现。一个设计良好的计算机系统应该在不需要修改的前提下轻易被扩展。

比如：我们先将满足不同需要的代码分组（SRP），然后再来调整这些分组之间的依赖关系（DIP），最后要实现的正是开闭原则。

依赖反转

依赖反转这个点，很多文章要么特别爱写依赖注入，要么就写接口编程，导致很多人不明白依赖反转的意思，似乎认为使用接口使用多态就是依赖反转。

如上图，控制流是从HL1到interface，但依赖流看起来是从ML1到interface。但要注意interface是由哪边定义，如果interface是由HL1定义，此为依赖反转，但如果interface是ML1定义的，这不是依赖反转。

依赖反转应该是使软件不再受控制流的限制，尽管HL1控制ML1，但通过提过接口，使ML1反而要依赖HL1，使原本上层对下层的强依赖，变成了上层定义接口，调用接口，下层对上层的接口进行实现，从而组织结构间出现了独立。

【读书笔记】代码思考相关推荐

[读书笔记] 代码整洁之道（一）
最近读完了马丁的clean code,颇有收获,简单整理下读书笔记,虽然整书是以Java代码做代码示例,但语言无国界,特别是编程语言更是如此,不管你从事的是以何种语言为主的开发环境,我相信,从本书中都 ...
读书笔记与思考（一）《MIT深度思考法》
何为思考呢?是基于一定阅历及对应知识体系下进行的推理与论证? 思考可以天马行空,放飞自我,犹如脱缰野马.思考也可以步步为营,娓娓而来,有若高楼拔地而起.对于复杂的问题,思考的过程犹如解答一道数学逻辑证 ...
《当狗养的男孩》读书笔记和思考
The boy who was raised as a dog, by Bruce perry and maia Szalavitz 这本书是我读过的几乎最好的一本关于儿童发育和育儿的书.读完以后我十 ...
逆向工程核心原理读书笔记-代码注入
代码注入是一种向目标进程插入独立运行代码并使之运行的技术,它一般调用CreateRemoteThread()API以远程线程形式运行插入的代码,所以也被称为线程注入. 和DLL注入相比代码注入占用内存 ...
[读书笔记] 代码整洁之道
书的示例是Java语言编写的,虽说不会影响阅读,但是后面几章讲应用这套方法论的时候,大篇幅的Java代码分析还是挺难受的,而且连java测试框架Junit都要细讲,对于非Java系的开发者来说,一些内 ...
02好好学习读书笔记-- 黄金思考圈
说实话,上次他们有人分享了画导图的"套路":what,how,why,当时我听了以后心里默默的来了一句:除了这三个还有三个你们没说呢,where,when和who. 但是今天看了& ...
读书笔记-代码的未来
简介 <代码的未来>作者松本行弘,日本人,Ruby之父,这是较为流行编程语言的唯一一位亚洲作者.之前有同学和我谈论说只是用别人设计的语言coding太low,能不能做语言的开创者,而不是使 ...
读书笔记：思考快与慢
公众号欢迎扫码关注本人微信公众号:公众号上分享更多嵌入式知识和资料,分享个人学习嵌入式的心得体会.欢迎大家一起来玩呀. <思考快与慢>是我花了好长时间才刷完的书,原因就是看的断断续续,更 ...
读书笔记 - 《思考，快与慢》
这真是很神奇的书!选择带这本书出差是因为它的厚度适中,说实话在书桌上堆了很久,我完全搞不清楚为什么买它.翻开书看到作者是诺贝尔经济学奖获得者,下意识觉得诺奖越来越水了:但看完书之后,我觉得收获巨大,作 ...
单元测试之道——基于junit的java单元测试的读书笔记与思考
第二章你的首个单元测试这一张已经忘了差不多,如何去测试,其实首先还是得先去考虑怎么去测试,这个就需要看代码单元的需求了. 一个简单的例子.测试排序第二章你的首个单元测试这一张已经忘了差不多, ...

【读书笔记】代码思考

前提：

类：

变量：

变量的名字：名字应该要能完整、准确地描述变量所代表的含义。

变量的作用域：作用域是指变量的有效范围，我们也可以简单的认为是变量使用之间的行数。

方法：

方法的名字：好名字非常重要

方法参数：最理想的参数数量是零，最多不要超过3。

类：

类的长度：第一原则是短小，第二原则还应该更短小

类的命名

类的成员变量：

良好的封装：

类与类（设计原则）

开闭原则

依赖反转

【读书笔记】代码思考相关推荐

最新文章

热门文章