凡事就怕问为什么（认识的升级）系列一

[Braisdom]

首先，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

该文档的确存在推广的嫌疑，但请理解。作为一个开源的作者，总希望更多人知道，我在不断推广的同时，也能体现项目的价值和我对项目的期待，如果项目对大都数人都没有任何意义，相信我也会很快放弃。

[IrisFrankie]

。。。

[DeepDarkVan]

老哥又开始了...........

[Braisdom]

@IrisFrankie
@DeepDarkVan

感谢你们的回复

[darling19961030]

老哥又开始了...........

[zhazi]

问题挺好。但是我面试的时候从来都问我 堆、栈、算法、数据结构、图、树。卷就完了。你聊这些你不怕面试官答不上来吗？

[zhazi]

另外说一下你的开源项目，现在国内市场讲究攀交情比名气。所以找个好靠山背书（比如阿里的开源）比研究这些见效快

[Braisdom]

@zhazi 那些都太技术了，多看几次，多试几次都能学会的，都是“术”，正在写过程序的人，有深刻理解的人应该都能回答上面的问题，是否全面就另说了。

[l00t]

问题提得太烂，打回重来。

[Braisdom]

@l00t 提提你的想法，贴出来，让我学习，我的目的不是传教，自我我的提升也很重要，

[l00t]

@Braisdom #9

体系化的知识学习里，一般已经包括了为什么要定义一个 method，为什么要定义个一个 class，interface 之类的东西了，这几乎是本入门教材都有…… 都不用再提。

而 Exception 什么时候 throw 什么时候 catch，日志怎么打之类的，更多的是一个策略，而不是规律或者知识。各人有各人的做法和偏好。

[wysnylc]

绝了

[Braisdom]

@l00t
1 ）日志打印，异常的处理，后续我会介绍，远远不是个人偏好，期间有经过大量程序员的错误所积累的逻辑和规律。
2 ）体系化的知识里只告诉你如何定义？怎么使用？至于为什么也是在大量实践过程中积累的。

个人偏好的确会用不同的方法使用，但背后的经验和规律则大致相同，所有的经验和规律都来自惨痛的经验。

既然你已经提出挑战，我们就讨论一下：“为什么要定义一个 Java Inteface ？”，大家也可以观点...

[gyh]

楼主的几个帖子都看了，特别佩服楼主冷静开放包容的态度，我觉得讨论就得是这个样子。

[l00t]

@Braisdom #12 体系化的知识怎么会只告诉你定义呢？难道是看的教材问题？

至于为什么要定义一个 interface，不也是早就写过不知道多少遍了嘛…… 为了分离声明和实现，为了多重继承，为了满足设计者的偏好。

[Kirsk]

吃瓜 坐等更新 做成知识付费也是可以的

[yukong]

老哥考虑来蚂蚁吗

[fewok]

时常问为什么容易陷入价值观。比如，为什么要做 java 的 ORM，而不是更简单更直接更需要强大功能的 golang 的 ORM ？？

[xuanbg]

还是不习惯说“方法”，习惯说“函数”，改不过来……

[yule111222]

@Braisdom 为了把类具有的某种能力（行为，方法）更高的抽象出来，方便外界调用或者去实现。个人习惯是一个行为现在或者将来有多种实现方式的情况下，大概率就需要定义接口。往后面讲会还涉及到依赖倒置和接口隔离等等，这里不细说。我认为国内的 JAVA 开发对于接口是滥用了，90%的接口可以不写，比如一些业务 service 类，在可以预见的未来根本不会有其他实现，就算有接口八成也要跟着改，根本不需要定义接口。

[haosamax]

一直疑惑的地方是异常处理，什么时候抛出去，什么时候 catch，不知道怎么选择

[Kaiv2]

楼主的开源项目很不错，如果 java 原生提供操作符的重载就更好了, 像实现了 Closeable 接口，就可使用 try 来自动 close，比如提供一个 java.lang.Add<T> 接口，实现 Add 接口 add 方法即可重载 + 操作符。这种使用接口标识，让编译器来处的方式更好。

[koujyungenn]

支持一哈

[Braisdom]

@l00t @yule111222 @haosamax

我来回复一下，但这只是我的理解，大家可以观摩：

1 ）面向对象中，有一个比较基础的概念，所有依赖都是抽象的，这也就是说所有需要外部类协调完成的工作都是接口，这也就 Spring 的概念，依赖都是通过接口形式注入，保证业务逻辑的动态性，Server, Mapper 等都是接口（当然有些是没有必要的）。

2 ）约束：每个子模块对外部的输入都是有一定性约束的，Java Interface 起到约束行为注入的约束，在 ObjectiveSQL 中 ModelDescriptor 就是很好的体现，子模块需要的信息通过 Descriptor 的形式进行注入。

3 ）规范定义：Java Servlet, JMS 是最好的示例，针对一组特性完整的定义，其实是一组接口，接口定义的只是概念，而不关心具体的实现。

在我们实际的工作中，Java Interface 的定义更多的是依赖的定义，重要的是我们对职责的分离，这是面向对象设计的基础，我先简单描述，大家有不想法可以挑战。

[Braisdom]

@yukong 细聊

[Braisdom]

@Kaiv2 你的想法很好，我给 Oracle 发了邮件，但那帮人比较传统，更多是尊重传统，Java 应该不太会支持，只能通过其它方式了。

[Braisdom]

@l00t

知识分两类，一种是别人传授的知识，另一种是自身体会的知识。随着时代的进步，有很多人传授你知识，如何分辨真伪，要靠自身的判断。我是一个分享知识的人，也是我切身的体会，你的挑战很合理，触碰到你知识的边缘，勇于挑战，是学习的动力，我们共勉...

[Braisdom]

@fewok ORM 是一种编程模型，所有语言都适用，是用一种视角去理解编程的方式，go 强不强大，是在它处理关系数据库计算时的能力，能不能适应复杂多种的应用场景。有兴趣加我微信，我们细聊

[Braisdom]

BTW: 这只是我的第一个系列，觉得有所收获的，请回复认可，我的分享也需要动力，如果总是不受待见，我也没有积极性了。


@koujyungenn
@Kaiv2
@haosamax
@l00t
@yukong
@wysnylc
@gyh
@zhazi
@IrisFrankie
@DeepDarkVan
@darling19961030

[taka8rie]

很高兴能看到楼主写的这些。☺️长期关注。

[Kaiv2]

认可,希望能给到你动力

[raaaaaar]

@zhazi #5 数据结构算法这些基础知识，和楼主说的语言的深入理解，并不冲突啊，最多个人精力有限，看怎么分配时间而已。

我认搞技术勤思考，多问为什么，多有求之问底的精神是很好的，这种性格会让自己接触到更深的东西。

[lzlee]

以前也觉得会用就行了
但是知道了一些为什么后, 很多原来生硬的东西变得自然了
而且一个领域的思路, 经常可能复刻到另一个领域
虽然说不上来具体的, 但是感觉对我很有帮助

不过现在还有些地方我控制不好

首先是 为什么 不知道怎么问
有的问题看似简单, 但是实际上很大很深
有的问题看似很大, 一上来能把人劝退, 但实际上却可以通过之前学过的东西组合, 演进
再或者多个问题, 如果按特定的顺序来处理, 会好理解很多
不知道有多难, 不知道先解决哪个
再配合一些轻重缓急, 很多问题只能记下来, 有空再去看
我目前只能优先解决反复出现的问题...

其次就是 不太会寻找答案
我感觉很多比较好的答案, 其实都是我之前积累的问题, 然后在看那种大书(比如 机械工业的那些黑皮书)的过程中找到的
自己平常搜索的博客, 质量层次不齐, 而且很多都没有上下文, 看似很顺畅, 但是要么比较片面, 要么藏了些坑
但是啃大书实在又太慢了, 还得做笔记...

不知道高手有没有类似的困扰, 还是说我太菜了

[echowuhao]

@lzlee 其实就是要学习历史。计算机也是有历史的，知道事情的来龙去脉才知道为何现在这样。

另外赞 lz 分享。分享夹杂软广，也是喜闻乐见。V 站确实不错，我发现 v 站后，就不上知乎了。

[echowuhao]

lz 说的都是有点。说一个 method 的缺点。一旦有复杂的继承关系，看 method 是个头疼的事情。

[Kirsk]

@lzlee 当你需要深入 你就得啃书没有得办法 有大佬带最好了

[lzlee]

@echowuhao
好的谢谢

[lzlee]

@Kirsk
嗯
之前有大佬在身边的时候, 不懂得珍惜, 不会学习
现在学会了, 稍微入了点门, 发现年纪也大了, 大佬也没了, 哈哈哈

[wangyuescr]

是不是又要我们教两百学费，号称自己多年开发经验，带徒弟

[laminux29]

如果你是正规计算机专业出来的，并且认真听课了，就不会有这些问题。

建议把 985 计算机本科的技能树，按课程设置依次点开，从高数与物理开始逐级向上，贯穿整个计算机与科学发展史，你才能彻底弄清这些问题。因为很多问题是历史发展的问题，没经历过整个历史阶段，很多问题你单独拿出来思考，是想不出啥结果的。

[Kasumi20]

@laminux29 又吹牛逼了, 哪个学校的老师教得这么细, 你不思考只听课, 估计只有请神仙来给你灌

[laminux29]

@Kasumi20 如果嫌弃老师讲的不好，可以自学，可以找别的老师问。

就算所有老师都答不出来，可以问谷歌。

有些东西，比如 64k 的仿 CS 游戏，比如 12306 架构问题，去问老师，的确有些为难他们了，但绝大部分基础问题，一个学校里的计算机学院，总会有老师知道答案。

[l00t]

@Braisdom #23 你这样的描述和抽象类有什么区别？你搞个抽象类也可以套上这一二三。当你要引入一个 interface 的概念的时候，你得指出它的特有之处，而不是共性。甚至我不 OO，我就面向过程，搞个头文件，一样能套这一二三。

我还是那句话，体系化的学习已经包含了你提的这些问题。

[DeepDarkVan]

老哥带带我吧

[Braisdom]

@l00t 至少三个编程概念是已经得到共识的，你翻看 JDK 的源码，或者 Apache 顶级项目的源码，基本都能看到。

1 ）对依赖的封装，2 ）对依赖的约束，3 ）对整体规范的定义

一项知识讲的太抽象，太空洞，能解释一切，其实你也什么解释不了，真正需要学习的知识是具体的，实际的，可验证的，这样才能对实际的工作有指导意义，否则讲太多理论，等于什么也没讲

[Braisdom]

@l00t 这三个只是接口的基本使用方法，也是能够很好解决为什么使用接口的规则，但不是强制规则，依赖的方式可以是一个抽象类，也可以是一个接口，但相比而言接口更合理。

至于过程化编程语言和面向对象的编程语言的差异，那是另一个话题，别总剧透呀。

[l00t]

@Braisdom #44 我再重复一遍…… 当你引入一个概念的时候，你得指出它的特有之处，而不是共性。如果它没有独特之处，那它有什么存在必要呢？

Java 为什么要搞出个 interface, 这要真是个题，那么最大的得分点只会在多重继承上。而这个点，也是几乎所有教材都会提到的内容，并不需要自己瞎琢磨。

我一路看下来，你的思路似乎都是顺毛撸，看到一个东西，啊怎么好怎么好，符合什么什么；但是计算机程序语言的问题大多时候更多的是个取舍问题。要达到一个目的，可以 A 可以 B 可以 C，为什么用 A 不用 B 不用 C，ABC 各有什么优缺点，选择用 A 而不用 B 或者 C 是个好的决策还是不好的决策，这个好或者不好的判断是基于什么而言。这些问题才更能抓住本质。而这些问题读一下各个特性引入时设计者自己的说明、语言的演变历史之类的可以解决很大一部分，剩下的才需要自己思考，想想他们说的对不对，有没有别的他们没考虑到的地方。

[Braisdom]

@l00t 你的问题很好啊，Java 为什么要设计 Interface? 是一个可以探究的问题，需要研究历史，和最初的设计思想，以及当初所面临的背景问题。

我讨论的是为什么要用 Interface，而不是为什么要设计一个 Interface，如果没有 Interface 又是一个什么样的编程方式？那是另一个话题。

我是以实践为基础，讨论 Interface 在我们的实际工作中到底应该怎么用？寻找不同 Case 之间的规律，提出指导建议。过于抽象的理论对实际工作基本没有什么作用，也就是现有的知识传授体系和书籍的通病。

[Braisdom]

@l00t 首先，要先明白为什么会出现软件设计这一个管理过程？它的目的是什么？它主要解决了什么问题？

要达到一个目的有很多种可选择的方案，但不同程序员选择方案的规律是什么？背后的原因又是什么？而不是简单讨论优缺点。

我总结出的是规律，就像为什么要定义一个方法一下，我不仅会阐述不程序员选择的规律，而且还会解释背后的原理。Java 接口的使用是一个很大的话题，不是在讨论区中能够讨论清楚的。我只是抛砖引玉。

[bjhc]

老哥又开始了。。。

[hello158]

我觉得楼主提的问题非常好，别的问题不说，就说 Exception 的问题，太多人没能用好，胡乱 throw,胡乱 catch 。

[xrr2016]

赞一个

[cian]

你草率了

[huZhao]

虽然我可能用不到楼主的开源库，但是这种分享精神，赞一下，老哥也可以关注一下 我的微信公众号 《独立自由职业者》，我也是爱折腾，爱分享的。可以看到一些干货。当然也期望有更多的读者能给予提高认知。

[l00t]

@hello158 #50 这个问题是需要琢磨，但是背后并没有什么“规律”和“原理”需要去发现，而是需要总结出一套适合自己实际情况的并且自己喜欢的异常处理机制。这套机制因人而异。

[l00t]

@Braisdom #48 这不是规律，也不是原理…… 你是不是对规律和原理两个词有误解？我为了实现某个需求，制造了一个工具，你跟我说这个需求是工具的规律？？代步是汽车的规律吗？

[xcstream]

为什么要定义一个 Method 因为 java 不让直接定义一个 function

[Braisdom]

@l00t “怎么用”，“如何用”是现象，的确会因人而异，但不同人之间使用同样的方式处理问题，背后是存在一定的规律，你可以看看 Apache 里的顶级项目，里面有很多共性，这些是我们去寻找的规律，为什么他们用同样的方式去解决问题，背后的原因是什么？

其它用什么样的名词本身不重要，没必要纠结名词的定义，挖掘背后隐藏的东西，能够指导我们进行工作，这件事有意义就可以。

[besscroft]

支持一波

[Braisdom]

@l00t 整理出来的异常处理机制是基础的规范定义，但规范就是规范，相对较为死板，但实际的情况总是多变的，不能一刀切的形式去解决问题。规范的定义只能给出抽象的指导意义，遇到实际问题时，很难套着规范就能做的。只有真正理解了 Exception 的基本原理，整理前辈们在异常处理时遇到的各种问题，理出其中的共性和规律，这样才能用好异常。

如果我用一句话表达我的观点就是：“所谓的规律和规范均来自于前辈们的错误和惨痛的实践，我们要做的就是把它们整理出来，用通俗的语言表达出来。”

[GoLand]

我还以为 APIJson 那哥们呢，当年那哥们推广起来也是真狠啊，无论在哪儿评论都要留下一个 APIJson 的推广。

[lance6716]

第一个问题：Method 指的是 https://en.wikipedia.org/wiki/Method_(computer_programming) 这个吗？ method 相对于 fucntion (self, ...) 的形式有啥优缺点？（对于编译型语言）在可执行文件中这两者哪种是更天然表达的？

[zypy333]

要是能带代码说就更好了

[Braisdom]

@zypy333 好想法，后续可以完善

[wanglulei]

如果有 demo,解释说明我觉得会更棒。持续关注一波。

[charlie21]

他们这个说法有一致性即可 自圆其说即可
有的人还出书呢 还卖得挺好。为什么呢？他懂得不被别人牵着鼻子走

[janus77]

以前看过一篇文章，里面一个核心观点，全都是为了复用。
method 是为了复用
class 是为了复用
abstract 是为了复用
interface 是为了复用
整个 OOP 的核心思想就是复用

[hihanley]

持续关注，但是这里似乎不太方便阅读，如果能将文章和有意义的讨论放在博客中会不会更好？
就像[为什么这么设计系列文章]( https://draveness.me/whys-the-design/)一样

[hihanley]

持续关注，但是这里似乎不太方便阅读，如果能将文章和有意义的讨论放在博客中会不会更好？
就像 https://draveness.me/whys-the-design/

[lzk50136]

我服了。。。又来了。。。

[Braisdom]

本人寻找工作，有兴趣内推的联系我：微信 braisdom