@Kirsk 空洞的原则和规律没有太大意义，就像面向对象的基本概念，封装、多态和继承，还有一些抽象的基本原则。太空洞了，看似包含了一切，其实啥也没有。我需要阐述的是具体的，实际的，就像“为什么要定义一个方法”，分析优秀的开源项目，从中找出可以验证的实例，并说明为什么，这些才是有意义的。

@Kirsk 原则往往比较空洞，而且原则很难适用于多变的应用系统，需要的是讲解不同人处理同样问题而使用同样的方法，背后遵循的规律。

@taogen 好想法，我目前只是介绍了，ObjectiveSQL 是什么？我需要仔细修改一下

@ytmsdy ORM 框架的选择是解决业务系统开发的易用性，而在大数据量插入时，可以手动拼接 SQL 的形式，不同场景不同的处理方式。

@Foredoomed 要理解 ObjectiveSQL 不是生成 SQL，而能用 Java 的语法写 SQL，你看到的 Java 代码几乎和 SQL 一模一样，是不是最优看你怎么写 Java 代码了。

Order.Table orderTable = Order.asTable();
Select select = new Select();

select.project(sum(orderTable.amount) / sum(orderTable.quantity) * 100)
.from(orderTable)
.where(orderTable.quantity > 30 &&
orderTable.salesAt.between("2020-10-10 00:00:00", "2020-10-30 23:59:59"))
.groupBy(orderTable.productId);

@ytmsdy

高性能和易用性本身就不可能同时存在，此消彼长，具体项目具体分析，不能一概而论。

@noble4cc 是的，有点类似，前期参考过 Jooq，发现 Jooq 有好多地方做的不够好，所以自己才写了一个，主要是针对复杂 SQL 进行处理，同时也支持简单 SQL 的处理。

@janus77 ORM 到底是什么，有哪些特征，很难说清，理论上，将关联数据库的表转换为 Java Class 都可以称为 ORM
@leonme 性能和易用性两者要平衡考虑的，两个指标不可能同时都非常高，封装是解决开发的复杂度，在不的场景中有不同的选择

@buliugu 估计你没有进项目里看，这里有完整的 benchmark 代码，

@taogen 这里有完整的代码： https://github.com/braisdom/ObjectiveSql/tree/master/benchmark

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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