为了账号安全,请及时绑定邮箱和手机立即绑定

具有延迟评估的订阅者

具有延迟评估的订阅者

Go
不负相思意 2021-06-11 18:08:11
我正在寻找订阅 Go 中属性更改的解决方案。鉴于以下结构,我想实现一个派生属性,该属性订阅其源属性,并且只有在被读取时它才会重新评估自身。如果一个或多个来源发生变化,它会通过收到通知或通过检查“脏标志”(频道?)来知道这样做。 编辑:我不是在寻找一个“getter”函数,它不会缓存获取的值,而是在每次读取它们时提取它们)。另请参阅下面添加的 DeriveAndSubscribe 方法,说明派生的 FullName 会做什么)。我想这类似于一个相当典型的案例。下面的例子:type Person struct {   /FullName  string  // Derived, from the two below:    FirstName string  // persistent    LastName  string  // persistent}对于远订阅/获取,该概念也必须是“可见的”,例如,从底层 Person 对象派生其详细用户信息的 User 对象:type User struct {    person *Person   /FullName string // Derived from person.FullName above}(好吧,人们的名字不会经常更改,但示例必须很简单)。我自己对此的第一个想法是,Pull - 派生属性 (FullName) 是“惰性的”(仅在有人阅读它/它们时才进行评估)。因此,仅在评估 Fullname 字符串时才“拉取”任何订阅(“脏”标志/通知)似乎是最自然的,即“询问”是否发生了任何更改。缓存- 派生该值后,将其存储在(隐藏)字段 (_fullName) 中,以便该字符串可以在下次读取时重用,如果其订阅值未更改。延迟订阅- 当有人读取 FullName 属性时,不仅派生操作应该是“延迟的”,而且订阅本身应该只在第一次评估时(当有人读取属性时)放置。使用 pull而不是 push 的充分理由似乎是,当底层属性更改时,订阅属性可能存在也可能不存在。如果源中没有“发送列表”,那么如果/当最终订阅属性/对象消失时,则无需“取消注册”。并进一步; 在分布式场景中(不同机器上的用户和人员),最好仅在实际明确要求数据时才更新内容(订阅也适用,只能在第一次读取 FullName 时放置)。豪华是如果够程(可选)可以更新(重新评估)FullName的属性(S)时,CPU是不是很忙,而重新评估将被立即执行,如果有人读FullName的属性(既可以在一个解决方案可以实现吗?) .无论如何,这里是需要铺设的订阅(ASCII 模型):[Person]./FullName --> [Person].FirstName // Subscribe 1                       [Person].LastName  // Subscribe 2和[User]./FullName --> [User].person./FullName // Subscribe 3也就是说,总共有三 (3) 个订阅来保持 User.FullName 属性的更新。(暂时忽略 [User].person-link)。可以使用渠道来实现这样的事情吗,如果可以,嗯……怎么做?在插入了隐藏字段的上述结构下方(用于缓存派生结果,直到下一次源属性变得“脏”):type Person struct {   /FullName  string  // Derived    _fullName string  // "cache"    FirstName string      LastName  string  }和:type User struct {    person *Person   /FullName  string  // Derived    _fullName string  // "cache"}
查看完整描述

2 回答

  • 2 回答
  • 0 关注
  • 169 浏览
慕课专栏
更多

添加回答

举报

0/150
提交
取消
意见反馈 帮助中心 APP下载
官方微信