肉饼的肉一般由猪臀部或者猪颈部等口味较差的部位，混合淀粉和蔬菜制成，成本很低的。

我在用 Microsoft 的 Exchange 邮箱托管服务，按用户数量收费，界面 UI 比 ZOHO 好看。

LOHO

组装一台主机。

刚装完机器，多出来一个刚拆封的海盗船 12025 风扇和全新 300mm 显卡延长线，有意低价转让。

支持 👍，谁谁谁说中国开源生态差，现在有了先驱者又群起而攻之，大型讽刺现场。

我同意 @reeco 的方法，使用事件驱动，DeleteService 只负责核心的删除操作，在操作完成之后发布一个事件 UserDeletedEvent，然后业务就结束了。

其他后续的删除操作委托给不同的类去完成，实现类监听 UserDeletedEvent 事件并完成后续的步骤。除此之外，UserDeletedEvent 可以包含 userId、userName 等数据供实现类获取上下文数据。

GoBiggeR

因为 Cache Line 的存在，所以严格来说 ArrayList 的遍历速度更快一些。

是有一点反模式的味道，建议使用抽象类 + 继承来实现基于多态的策略模式。使用枚举实现多态有一点强行绑定的感觉。

想问一下你是用什么软件作图？

@oott123 我觉得楼主的意思不是使用 Git 对文章进行版本控制，而是参考 Git 使用树结构和不可变对象来索引存储所有的文章。

认真地看完了 commons 和 http 中的代码结构和风格，想看一下楼主是怎么对方法进行单元测试的，结果发现 test 包下只有一个 package-info.java。

我认为楼主的出发点是好的，对常用代码进行封装以简化开发。但单层封装并没有使库的抽象程度提高，对于 API 的调用者来说只不过从学习标准库的调用方式变成了学习楼主提供的调用方式，而对于实际问题来说，使用 protocols 之前问题模型是什么样，使用之后还是什么样。

其次是毫无“单元测试代码”，也就是说没有任何代码能够证明楼主提供的封装库的可靠性，简单地归纳常用代码的同时也引入了新的操作，中间每一步都有可能出现问题，尤其是频繁使用的公共库，抛开知名度不说，没有单元测试的支持让我很难在众多公共库中选择楼主的 protocols。楼主可以阅读一下 OkHttp、Netty、Guava 的单元测试代码，或者了解一下 JUnit 和 Mockito 的使用。

一点建议，供楼主参考。

@everding 产品名称太难记了，一个单词就够了

上 36Kr NEXT 了啊，恭喜作者。

@kaneg 有道理

@vankid @zgbgx1 刚刚看了下 Java 中的声明，Queue 这个接口同样继承自 Collection，但是并没有显式声明 size、isEmpty，但是 List 和 Set 都有。但是 Queue 中声明的 add 和 offer 方法却在子接口 Deque 中被重新声明了。

而且我注意到 Queue 的作者（ Doug Lea ）与 List/Set 的作者（ Josh Bloch，Neal Gafter ）不是同一人。所以我猜测重复声明一方面是个人习惯，另一方面是显式告知使用者该方法在当前上下文和父接口上下文中使用方式和含义的差别，比如 Queue 中的 poll 就是 poll，而 Deque 中的 poll 和 pollFirst 等价。