标签：play amp aml AMM 其他 情况 承担 main 调用
忘记是高中哪个老师讲的一个道理, 可能是政治老师
"挨骂的都是没犯错的人"
原因很简单: 有一天, 班级上有几个同学逃课了. 这个老师在课堂上大发雷霆, 说了很多狠话, 最后冷静了下, 淡淡的说了上面那个极具哲理的话, 还说, 你们这些没有逃课的同学在这里挨骂, 真正逃课的人却没有挨骂. 从此印象极深.
虽然当时就知道这句话半对半错吧, 但是有很多事情总是掺杂了这个道理在里面
比如 假如最初, 大家都自觉买票乘车, 有一天,有个人故意逃票被发现了, 于是管理部门增加了一个检票的流程. 将所有人的出行成本增加了, 还不算增加的人力和设备开销
甚至可能还不能抵消逃票带来的损失, 但是你不得不这样做, 因为有人破坏规则了, 不受到惩罚的话, 情况会恶化, 当然最好的方式是各种技术保障手段, 增加流程只是最差的措施
这就是一个明显的, 没犯错的人承担了犯错人带来的后果.
当然,这是个技术博客, 自然要把话题绕到技术上来
有些接口的设计就充分的体现了这个 没犯错的人会受罪 的道理
比如有个接口, 需要判断角色是不是队伍的队长,
设计接口的时候,如果光想着通用, 就会设计成这样: Player.isTeamLeader(playerId)
这个接口很奇怪. 我属于一个队伍, 但是判断队长的接口在我身上. 而不是在队伍逻辑上.(不是重点) 其次, 你搜索下整个项目, 发现绝大部分的代码是这样写的: mainPlayer.isTeamPlayer(mainPlayer.id)
一般来说. 绝大部分的逻辑都是判断主角自己是不是队长, 很少有逻辑是判断别人是不是队长. 即很少有这种逻辑: mainPlayer:isTeamLeader(otherPlayer.id)
所以, 大家会为这个"通用"的设计思路买单, 每个人都会在调用时, 多写一个看起来很蠢的参数, 这样反过来说明了, 这个接口, 根本不应该在玩家身上, 而是应该在一个TeamManager里面.
例子不是特别恰当, 接口的位置是更大的问题, 但是结合上面的例子, 应该明白, 这样的接口设计在代码中比比皆是,
没有考虑用户使用习惯, 没有拆分接口, 希望一个接口处理所有事情, 导致这个接口的使用必然是五花八门的, 参数链会因此变长, 变的难看, 你用几个, 我用几个, 不同组合不同花样, 反正加一个,设置好默认值不会影响其他人
但是你敢动一个试试?
所以, 路过这种接口, 请保重
标签：play amp aml AMM 其他 情况 承担 main 调用
原文地址：https://www.cnblogs.com/wmalloc/p/11215202.html
