编程中包、类、变量、方法的命名问题的思考与点滴积累

编程中对于包、类、变量、方法的命名的思考

日常开发中对于命名的问题一直是一个头疼且头等重要的问题。好的命名可以很大程度上方便别人的理解与维护，但不合适、粗糙的命名就会将人带入歧途，我自己在工作中也曾深受其害，良久～

以下是我自己在日常工作、学习的总结与自己的心得体会，没有百分之百的对与错，只是在现阶段的我看来是最为合适的一种方式。欢迎讨论，但切勿较真。

为什么命名会如此痛苦

归根结底，我认为是英语文化与汉语文化在表达上的天然差异所造成的。作为使用汉语为母语的Coder，在日常的需求沟通、设计中更多的使用汉语进行表达，但在coding时使用的又是英文，而使用英文去表达汉语的意思时，总是会有一定程度上的失真，据一个典型的例子：四大名著中的《红楼梦》的英译本命名为《A Dream of Red Mansions》或者《The Story of the Stone》，但是这两个翻译都失去了精髓。

再者我们对于英文的学习还是停留在纸面上，对英语文化的理解并不多，所以就造成了在使用英文中的一些“近义词”的时候，无法很好的区分它们的细节含义，从而无法更加细致的区分使用哪一个更为合适。

在需要梳理逻辑或者交流逻辑的时候，又需要将英文编写的代码转为汉语表达出来，这里的英译汉并能完全逆向开发时的汉译英，所以经历了从汉语到英语再到汉语的过程，理解起来会更加痛苦与困惑，这个时候就会更加觉得代码中的命名不合适了。

根包的命名

这个没什么好说的，业界传统，组织/企业/网站的域名倒叙风格，大家也是如此遵守的，已经成为事实上的规定。

模块下子包的命名

模块下的子包，按照传统的MVC方式开发时，一般会有以下子包： 1. 基本的controller、service、common、util包； 2. 用来放置各种配置的config包； 3. 对于数据资源，我会使用一个datasource包来统一管理，无论是：mysql、oracle这样的关系型数据库，还是redis、mongoDB、ES等使用到的映射对象，都会在datasource.po下。 4. 使用mybatis的时候还会有一个专门用来放置各种数据库操作接口的datasource.mapper包，并且其中接口方法的命名，从数据库的角度出发，而不是业务场景； 5. 在使用mybatis的时候，仅仅是只有一个mapper我觉得是不够的，应该将对mapper接口中方法的调用封装起来，以服务的形式向上提供，而不是直接在service中直接调用mapper接口中的方法。对于此类的封装类以Processor结尾，使用processor包来管理，processor中方法的命名则是从业务场景的角度出发。 6. 使用feign时还会设置一个用来放置接口代理的client或者proxy。我个人更倾向于使用client，具体原委在下文中介绍。 7. 对于复杂/可重复的业务逻辑，使用单独的类进行管理，这种类的命名为以Handler结尾，包则以handler命名。在handler包下，会细分为async与sync来分别管理一步方法类与同步方法类。

使用mybatis时，对mapper接口中的方法进行封装

mybatis是一个优秀的框架，可以为我们减轻很大的工作量。但其也不是银弹，不能一次性解决所有的问题。在开发中，我们对数据的操作会有不同的要求。例如在查询数据时，有的场景要求查询到null时返回null或者一个特定的对象，但是有的场景要求查询到null时要求抛出异常报错。当这样类似的场景多起来的时候，如果在每一次调用mapper接口方法的时候去单独写逻辑判断，这样会造成重复代码，给维护带来了不便。

另一个原因，也是我认为需要对mapper接口中方法进行封装的最主要的原因：当业务场景复杂时，对mapper接口的维护也会带来负担。

对于一条数据的修改，一般会使用update直接进行修改，不同的场景下修改的字段不一样，若在mapper接口中定义一个update(PO)方法，所有的场景下都调用这一个方法，让人在阅读代码时会产生疑问”这个地方的update，到底是在做什么“？但如果在mapper中按照业务场景命名接口，将会使mapper变的很庞大，如果恰好这时使用的还是XML组织管理SQL，那XML文件也会变的庞大且难以维护。

所以在mapper中仅提供update、select、delete等简单的从数据库角度命名的方法，对mapper接口中的方法进行二次封装，封装进processor向上提供服务，在processor中方法的命名按照业务场景进行命名，并严格控制方法的参数列表。

processor与handler的区别

日常开发中在service之外会需要一些“处理器”进行抽象，英文中的processor与handler在释义上都有“处理器”的含义。但是从英语的语言文化上来说，handler来源于handle，handle有“钩子、把儿“的含义，所以在linux中对handle的翻译是：句柄。据于此我对handler的理解与定位是此类处理器要有一个分辨的过程，就像是在挑选，然后使用“钩子”将其勾起然后使用，更偏向于回调函数（callback）的程度，而对于processor则是直接的不需要挑选的来之即用。

feign的客户端倾向起使用client包管理，并且以Client作为类命名的结尾

feign是声明式的web service客户端，在这个组件的开发定位上就是一个”客户端“，所以我更倾向于使用client来命名。

今天就先写到这了，有了新的心得与体会，我会再补充进来。