凡事就怕问为什么（认识的升级）系列一
首先，V 站是个很好的平台，活跃度很高，同时能听到各种不同的声音，修正自身的认知。这个系列是我一直都想整理的，它是我以前在面试时经常会问的问题，很多同事希望我能把比较准确的答案整理出来，大家互相学习。借着这段空闲的时光，认真整理一下，共勉。
很多时候，我们学习一门知识或科学，在编程领域学习一门编程语言或第三方框架，体系化的知识总是能很快掌握，但背后隐藏的规律和原理却不容易被发现。本质上，那些原理和规律是我们已经知道我们不知道的东西，其背后还有很多我们不知道我们不知道的东西，这就需要我们学会不断的问为什么？以 Java 编程和 OO 为基础：
- 为什么要定义一个 Method ？什么时候要定义一个 Method ？
- 为什么要定义一个 Class ？
- 为什么要定义一个 Interface? Interface 的作用是什么？
- 为什么要定义一个 Exception ？什么时候应该 throws ？什么时候要 catch ？
- 什么时候要区分静态方法和实例方法？为什么？
- debug/info/error 日志在什么时候打印？为什么要打印？
- abstract class 有什么用？为什么要定义？
- 面向对象到底和面向过程有什么本质的区别？为什么？ …
还有很多，甚至会问为什么会出现 Java 语言？设计模式的作用是什么？为什么它会流行等等，不断的问自己为什么，其实就是一种认知的提升。这种哲学式的思辨，也能树立自身的理论，而不是只会认为：它本来就这样，大家都这么用，我也这么用了。现有的所谓系统化的理论，只是教给你知识，却很少告诉你为什么？很多知识只是告诉你创新的结果，却很少告诉你创新的过程和原始的动力，“凡事就怕问为什么” 系列，我以我的认知水平描述一系列“为什么”背后的规律和初衷，欢迎讨论和批评。
系列一：为什么要定义一个 Method
Java 中的 Method 是传统数学的过程化的概念，它的定义和表现形式不再详述，只是从最原始的角度分析？在我们编程的过程中，定义一个 Method 的场景有哪些，寻找其背后的规律，从而形成自身的理解。
- 过程分解：通过处理一项复杂的业务，需要大量的代码的协作完成，一层一层分析业务及代码的特征，将复杂过程分解为多个小的过程，参数和返回值是协作沟通的协议。
- 过程重用：设计的过程是通过迭代的方式，一步一步理清复杂的过程，然后过过程分解，并抽象反复被重用的逻辑，分析调用者特性，设计参数和返回值。
- 过程描述：一组相关代码的组合，很难体现实际处理的业务，代码的注释想要体现实际的运行过程，就需要强制反复的更新，一个 Method 的名称就是描述实际处理过程的最佳方式。
面向对象中，Method 被定义为对象的“行为”，是沿用传统过程化编程的概念，将复杂问题逐步分解的一种编程方式，起到描述业务实现逻辑的作用，既然是描述业务特性，其命名就应以业务概念为基础，相互协作的方式也应遵循业务领域中的逻辑特征。当然，业务逻辑的代码实现过程中，也会存在纯粹的程序化的概念，或者交织的概念，这些概念所产生的 Method 没有固定的标准，其实也就是对纯粹程序化概念的英文命名的习惯而已，可以参考 JDK 的代码或者 Apache 项目的代码。
经过上面三种方式的定义，我们基本可以理解为什么要定义一个方法，以及常见的定义方法的必要性，通俗点讲，就是将问题不断分解，使得每个过程都能清晰描述业务实现。我按我的理解, 再补充几点容易识别的必要性：
- 复杂表达式的计算：表达式（例如：”加减乘除“或”复杂逻辑判断“等）通常过于抽象，无法准确表达实际的业务特征，通常我会将其封装为方法，通过方法名称表达业务特性，过于复杂的，再通过方法注释加以说明。
- 复杂数据构造：例如：字符串拼接、根据逻辑判断获取不同数值等方式，类似于”工厂方法模式“，但相对比较具象。
- case 逻辑体：switch case 或者 if esle 中如果判断条件较多，则通过定义方法描述不同条件下的处理逻辑。
- 抽象封装：如果控制逻辑为调试抽象的调用，例如：Map, Set 等数据结构的使用，put, set 等，需要将一组抽象行为封装为有业务特征的方法。
总得来说，代码不仅是写给机器执行的，更多的是写给人看了。代码是活着的业务文档，注释是补充说明，更多的是需要可运行的代码说明。上述只是我个人的见解，欢迎补充和挑战。
本人最近在找工作，有合适岗位的可以联系我：微信：braisdom
我的开源项目： https://github.com/braisdom/ObjectiveSql
该文档的确存在推广的嫌疑，但请理解。作为一个开源的作者，总希望更多人知道，我在不断推广的同时，也能体现项目的价值和我对项目的期待，如果项目对大都数人都没有任何意义，相信我也会很快放弃。