2018-7-4 10:08:24 星期三
有些感悟, 一些东西如果设定一些准则, 他可能规定了你至少要做哪些事情 / 你最好这样去做
根据准则去执行, 就会减少不必要的遗漏; 对莫能两可的事情快速做出决定, 不再纠结
如果心里没有一个标准, 每次开发都会觉得这样写也可以那样写也可以, 左右为难, 最后感觉只要能实现当时的需求, 完事就可以了, 不管那么多了, 最后代码就比较乱, 没有规律, 隔一段时间后自己都看不懂了.
用例图, 流程图
他们规定了我们至少考虑的几个方面: 1. 用户是谁, 2.用户怎样使用, 3.操作对象是谁, 有了这样一个"准则", 我们做方案设计的时候, 就少了些不确定性, 因为这些是必须考虑的
比如: 要先确定这个功能是谁在使用, 这就涉及到用户的角色, 和其所拥有的权限控制, 相关操作界面怎么显示等等, 这样你就不会遗漏对用户权限控制的功能开发
情景: 我最近做任务单分配的功能, 一开始沉浸在里边一直想, 这个类型任务单怎么分配给谁, 那个类型的任务单怎么分配给谁, 等想好了这些,
确被提醒说, 没有考虑人工干预分配的情况, 我这才回过头来从头考虑, 谁在使用这个功能, 在什么场景下使用这个功能:
使用代码自动分配 -> 部门内分配,
有权限的上级部门的同事 -> 跨部门分配 -> 分配给部门负责人 -> 再由代码分配
再比如一个方法究竟定义几个参数合适的问题,
1. 有人觉得语言本身又没有那么严格的限制, 我想怎样都可以
(相反的观点: 如果太多参数, 一是调用时必须按照参数顺序传输, 即使有些不用传也得传空, 二是参数越多逻辑就很有可能越复杂, 改都不敢改, 三是一些时候其实只需要其中一段逻辑但是仍然要走很多无用的判断, 甚至取出很多无用的值 )
2. 有人觉得最好只定义1个, 一个参数一个结果, 很纯粹的方法, 一看就知道需要啥
(相反的观点是: 1个参数的话方法过于简单, 能处理的逻辑有限, 必须通过多个方法去实现一个目的 )
3. 我个人觉得最好不超过两个, 参数不多记着也方便, 大概也能猜出方法是干啥的, 可以控制稍微多一些的逻辑, 但也不会太多, 阅读也方便
上边说的是单个的方法, 那么对于类的构造方法呢?
问题: 构造方法是一个类的入口, 比较特殊, 它要做一些初始化的操作, 因此很多构造方法要写很多参数
现实: 但是经常遇到的情况是, 之所以要写一个单独类, 很可能是为了把一些方法整合在一起:
1. 可能这些方法是处理同一个数据库表的, 这些方法被其他功能模块使用, 并不依赖构造方法的参数
2. 也可能是为了实现一个共同功能模块的方法的集合, 这时, 很多方法也并不依赖于构造方法的参数, 有些甚至不需要参数, 独立的可以单拎出去
构造方法的作用一般是 根据传递来的一个或几个参数, 再获取出一大堆相关的数据作为成员变量,
但不是每个成员方法都需要全部的成员变量, 如果都放在构造函数中去初始化, 难免会浪费资源
我的方案: 构造方法尽量少的定义参数, 每个成员方法也要有必要的参数, 以便让其他调用者知道该传什么参数