@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

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

@l00t

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

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

@yukong 细聊

@l00t @yule111222 @haosamax

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

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

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

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

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