@XCFOX

我写过一丁点 unity ，unity 本身就非常 DI 。对于场景设计器之类的东西静态定义的对象，框架控制着对象容器，写的逻辑会被框架反向绑定到对象上，逻辑类（ XXBehavior : Behavior ）是通过 unity 提供的 API 来获取自己绑定的物体实例的，物体不持有逻辑逻辑也不持有物体

有啥好看的，拿锤看钉罢了

第一性原理： IOC 是什么，解决了什么问题

- 是什么： 当我在一个纯 OO 语言里，想用到某个 object 提供的方法时（比如 A 类的实例）需要 a=new A; a.method()
但我不希望当前写的这个逻辑依赖死 A 类，我希望有个「只要跟 A 类差不多的类实例」就行。于是可以使用接口+工厂，即 a=AFactory.New();a.method()，但这个实现依然要依赖特定的工厂，我希望写任何逻辑都能有一个万能工厂提供我要的接口，于是我不再在逻辑里写 a=new A 了，我写 a=THEGOD.provide("A")，或者在我的构造函数里写 CreateMe(I_WANT_AN_A a)，这样我就有 a 了，怎么来的我不管，谁爱给谁给。

- 解决什么问题：
1. A 经常变化，我无法自己得到正确的 A ，但 GOD 可以，因为 A 会告诉 GOD 怎么生成自己
2. A 就算变了，我不需要配合改变，「代价」比较小




好，现在思考这两个问题在 golang 语境的意义

先说代价。因为这是最显著的差异
golang 是一个需要编译成二进制的静态类型语言，而且所有的代码都在同一个二进制里
它不像 java ，改了某一个模块，仅仅是那个模块的字节码发生变化。java 甚至可以动态加载字节码，也就说它完全可以 core 保持运行，临时下线一些功能，加载新的字节码，将原功能指到新加载的字节码上。
但 golang 不行。
****任意代码的修改都会导致整个程序重新编译****
编译时长之类的问题可以通过缓存文件优化，但是
****服务程序必须全部停止****
这一点是不会改变的。无论怎么折腾，golang 写的代码都必须重新编译，且**完全停止**原来的二进制程序运行再跑一个新的。
因此相比于 java 语境中「代价」有重大的运行时意义，golang 语境下「代价较小」的意义仅仅是保持代码工程的相对整洁罢了，但源码组织是整个软件工程中相当不重要的一环，我想没什么人会否认吧。大家都住在屎山，但没听说哪里的代码写成喜马拉雅能跑写成屎山就跑不了的。



再说问题 1

// service.go
var a IA = NewA()
a.method()

// interface.go
type IA interface{ method() }
func NewA() IA {
if 1{return a.NewA()}
if 2 {return a.v2.NewA()}
}

不行吗？
service 不引用 A 吧
interface 要改，但跟改 xml 本质上没什么区别吧



另外静态语言都不热衷这种框架，因为就算语言提供反射，它们也不像动态语言一样能「凭空造出一个类和实例」，从本质来说它们只能「改变指向类型的指针」，因此只要类型结构本身没有编译到二进制里，无论怎么折腾也造不出一个新类型。

这也就意味着 IOC 框架再怎么折腾也需要一个已经存在的类型实现，而非只要有存根就行。
因此在这些语言里，让框架为使用者寻找一个 IOC 容器的意义也仅仅只是在一个编译期就确定的类型映射表里找一个合适的类型罢了

那我代码里直接用这个静态映射不就好了，我干嘛还要「委托框架来帮我找」




----


拿你提的这个框架来说
1. 不使用这个框架，只用 interface 是不是也能从代码上解耦？
2. 使用这个框架，接口实现变化是不是一样的要「改代码+重新编译+重新部署」而且改动范围差不多？

golang 生态在微服务化跟 java 生态在 bean 化都是需求和语言特性 /限制的「磨合」，反向照猫画虎反正我的心态都是看个笑话

假设 c++库 /程序叫 core:

- core 在内存中保存配置或者控制位
- core 如果需要被外部控制，可以序列化成比较通用的结构化数据比如 json/msgpack ，外部控制器（比如 golang 写的 web 后端）来负责持久化它们，存取数据库之类的，core 只解析 web 后端传过来的结构化数据
- 转发器直接将流量转到 core ，比如 nginx module 或者集成了 libpcap 的东西，它们可以直接通过 IPC 手段与 core 存取同一个共享 buffer
- core 执行必要的计算并且在内存中保存计算状态
- 等待 web 后端异步地来读取这个状态，或者 RPC 通知后端状态发生变化
- 在 RPC 里传递计算结果，这时候就还是通用结构化数据

c++后台一般不直接跟 web 交互

可选的方式有：
1. 编译成动态库，暴露 C ABI 的 API ，这样 goalng 之类的后台基本可以即插即用（需要共享一个头文件和一个不需要实现具体功能，即 stub 的动态库二进制文件）
2. 使用 unix socket ，交互 json 数据或者 protobuf 之类的（无队列）
3. 使用消息队列中间件，随便选一个两边语言都有 binding 的

北京灵活就业必须京籍。

看来你在深圳。

我这有一个收藏了十几年的网站，虽然没什么用，但，它很特别：
http://humanum.arts.cuhk.edu.hk/Lexis/lexi-can/

const char(&a)[N] 是一个 有 N 个元素的 char array 的引用
https://stackoverflow.com/questions/13081837/reference-to-an-array-in-c

并且 N 是一个模板参数，因此任意长的 string literal 都能匹配这个模板。N 是模板匹配的结果

fetch remote status
get information & privacy
query by parameters
find pieces in un-indexed space
read while seeking

@windplume
@doublleft

没啥好纠结的，最好的做法是第一个词不小心用了 get 就全 get ，第一个词写了 query 就全 query

read 这个词我只会在「有一个打开的文件+游标+一个 buffer 」的时候用

@marcong95
> 因为我看 B 站似乎不会断了


那是因为 B 站把所有视频码率缩减了，视频流变小了而已

内存。
无论开发还是学习 虚拟机都是第一需求（因为还有 docker 存在），虚拟机+浏览器+IDE 会迅速耗完所有的内存空间，我现在 32G 的内存都不轻松，经常需要检查一下哪些窗口应该先关掉或者先把一些容器停掉。

18 年的时候配台式机感觉 32G 能虚荣一小会了，20 年的时候入手的 mbp 32G 就感觉已经是刚好够用了。 下回换掉我的台式机的时候应该会想办法搞到 128G 以上内存

你的接口是一个动作语义


你已经不 restful 了


趁早放弃残废的 restful 开始 post 一把梭还有救



你可以美其名曰 lite-json-rpc