kahlkn 最近的时间轴更新
kahlkn

kahlkn

V2EX 第 237934 号会员,加入于 2017-06-30 08:54:27 +08:00
根据 kahlkn 的设置,主题列表被隐藏
二手交易 相关的信息,包括已关闭的交易,不会被隐藏
kahlkn 最近回复了
试了一下,明白你的意思了。

```
List<? extends Animal> list = new ArrayList<Animal>();
list.add(new Dog());

Map<String, ? extends Animal> map = new HashMap<String, Animal>();
map.put("str", new Dog());
```

会出现错误:“
add (capture<? extends test.bean.Animal>) in List cannot be applied
to (test.bean.Dog)”


感觉无力解释,只能说 ? extends Animal 不应该用在这个位置。 一般来说可以这样用,表示可以传入一个 list,可以是 List<Animal>,可以是 List<Dog>,可以是 List<Cat> 。
```
public void takeThing(List<? extends Animal> list);
```

如果需要 List 中可以同时存入 dog 、cat,直接这样就行了。
```
List<Animal> list = new ArrayList<Animal>();
list.add(new Dog());
list.add(new Cat());
```
绿米空调伴侣 还把我家空调弄坏了呢。 (可能有功率限制,但是在怎么限制 普通空调应该得支持的,我家是 1P 的空调)
我觉得如果是单纯的业务系统中的业务代码部分,大概率很难碰到。碰到的话,因为思维惯性,也会考虑 if else 方式解决。 我之前碰到过一个 根据传入的 Code 走不同业务的需求,if else 也能解决,策略模式也能解决。大致就是业务代码中设计模式很难碰到,碰到了也是惯性的 if else 。

不过如果写的是 框架代码,每个公司都会有的自己的框架包的那种代码,那里面出现涉及模式的概率比业务代码大得多了。
47 天前
回复了 aqtata 创建的主题 程序员 你们用 get/set 吗?
@xiaomingVTEX 对于这位兄弟摘录的面向对象封装这块我觉得没有任何问题。

但是如果到了具体的业务场景的时候,我觉得可以 分为 偏业务实体 和 偏数据实体。这位兄弟中的 setPassword 我觉得属于数据实体的范畴。而 changePassword 属于业务实体的范畴。并且这类业务实体,偏向充血模型(即将具体的业务行为放入到实体中)。本人作为 java 开发,java 中的实体偏向贫血模型(即实体更偏向于作为数据的载体,具体的业务行为不放入实体中)。

至于 getter/setter 问题,反正 java 开发者必须写,除非你不打算用主流的框架。至于好处嘛,除了之前一位兄弟说的断点时可以监控外。 另外的作用就是 可以 在方法内 增加一些业务逻辑(尽管 java 中不建议这么做,但是对于一些紧急的需求修改上,可以临时的快速的搞搞,比如某个数据变形、裁切之类的,由于调用点很多一个一个改不方便,直接改 setter 中的内容,或者 getter 中的内容即可,前提评估好影响)。当然在 spring 等很多框架中,一些内部类或者包级别的类,可能有不少就直接 user.name 这样使用的。
@zzl22100048 本质上都是用来做 三方登陆 的,都可以说是属于 认证 把(应该把)?。 OAuth2 第一步是 授权,第二部 根据 access_token 获取用户信息,不就算是 认证 嘛。 oidc 第一步 就返回了 id_token,而 id token 又包含有用户信息,所以称为认证。
首先 阿里云 确实有 JWT 的应用,这个让我确实很高兴,毕竟终于见到 JWT 的大厂的应用场景了。就是 @a728976009 说的 oidc 。 https://helpcdn.aliyun.com/document_detail/93698.html

然后 了解了一下 oidc,感觉 OIDC 和 OAuth 的不同,就是 用 JWT (这里的 JWT 指这种机制,毕竟不同的签名 /加密名称不同) 来做了 用户基础信息 的载体(比如 用户 ID 用户名称),用户的其他信息 还是需要 调用接口去取的。然后因为 OIDC/OAuth 都是用来授权,或者三方登陆的,没有普通业务场景那么多问题,直接 JWT 传过去来获取用户信息就好了。

优势,原来 OAuth 需要 先获取到 access_token ,再去调用 接口 获取用户信息。 而 OIDC 直接 返回了 id_token ( JWT ) 和 access_token (可有可无看服务商),对于大部分 只需要 三方的用户 ID 和 用户昵称的 场景,这样一步就够用了。

至于用 JWT 去获取用户信息这个场景,本来服务于三方授权这样一种业务,你不可能说为 access_token 之类的 还设计什么角色、权限、接口权限 之类的 rbac 那套玩意,毕竟三方授权对于调用者来说我仅仅需要该用户在你网站上的部分用户数据。所以 JWT 的方式其实相对来说 优于 类 session id 模式。

而且那些把 JWT 用来业务系统中的一些问题,比如基本上都不会出现。
我们的 分布式 应用场景,就是由 认证授权模块 统一生成一个 类 UUID 的 token,用户登陆成功后,返回给前端,反正前端看着保存呗,别弄丢就行了。 然后每次请求的请求头 都会带有 这个 token,至于多域名跨域问题? 后端配置哪些域名可以进来就好了。

流量 -> 阿里云 LBS -> 业务服务器 Nginx -> 网关 (校验 类 UUID 的 token 是否合法,是否有访问这个接口的权限)-> 业务模块 (获取用户信息工具 根据 token 获取用户信息,并存入 threadlocal )

如果用户信息存入字段,仅仅存入比如用户昵称几个字段,业务上不一定用得到,还得去查一次,如果都存,一些业务的用户信息敏感不敏感先不说,单纯数据量,就很多,上面的 获取用户信息我们设计的也是分段获取,即你要一个用户属性,会自动拉去一定的用户信息到 threadlocal 中,不全部拉去因为多,也不能保证都用到。

是,jwt 是减少了 网关层面的 一次查询,也仅仅是 token 合法性校验的查询 省去了,但是 接口权限 校验还是要查的把。后面业务模块中获取用户信息大概率还是要再查一次的把。所以呢,JWT 最后还是变成了一个 类 session id 的东西。

至于水平扩展,网关受不了了,加机器。业务模块受不了了,加机器。注册中心大概率不会受不了的。 想怎么加就怎么加,只要有钱就行。
如果 jwt 真的那么好,那么你们会发现 各种开放平台,比如 微信三方登陆,阿里云的各种接口等应该都走 jwt 才对。 然而并没有,他们的 appSecret 也好 accessKeySecret 也好,没有一个走 JWT 的。 他们的量级够大把,他们的开发团队够强把,如果这个机制( JWT 的思路,毕竟大厂,也许会自己造轮子)真的好用,他们应该会用上才对。

看看微信的 三方登陆,拿 appId 和 appSecret 去换 access_token (类 UUID 的字符串,其他参数不管)。然后其他接口比如 获取用户的信息的接口,是需要传入 access_token 的(这不就是类似于 session id 的机制嘛)。

人家大厂还在用类似于 session id 那套,等哪天各种 各类的技术博客啥的(比如 美团技术团队 那个博客,还有一些大佬的博客)都强推 JWT 了,再考虑 JWT 把。
87 天前
回复了 polyang 创建的主题 程序员 有没有感觉现在的 JWT 都被滥用了。
是的,我记得还有个场景也挺适合的 淘宝(网页版,或者阿里云网页版,当然仅仅是猜测) 在登陆后,过一段时间,来浏览网页的时候,右上角是登陆状态,并且有昵称的。 可以进行正常的 非敏感 操作的浏览,一旦涉及到 稍微敏感点的操作的时候,就会要求重新登陆。

目测(在线猜测)这个是类似于 双 token 模式,即 jwt token + session token 的模式。session token 的生命周期可能浏览器关掉就结束了,或者 无操作 2 小时之类的就结束了。 jwt token 的生命周期可能为 2 天之类的,其中内部保存着 比如 用户昵称之类的信息。 由此才产生了类似的效果。
87 天前
回复了 panky 创建的主题 创业组队 [搭团队] 一起做一款 App 产品
Java 后端 a2FobGtuQDE2My5jb20=
关于   ·   帮助文档   ·   FAQ   ·   API   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   1799 人在线   最高记录 5497   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 8ms · UTC 16:15 · PVG 00:15 · LAX 09:15 · JFK 12:15
♥ Do have faith in what you're doing.