对开发准则的一些心得
Posted ilovemyd
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了对开发准则的一些心得相关的知识,希望对你有一定的参考价值。
2018-7-4 10:08:24 星期三
有些感悟, 一些东西如果设定一些准则, 根据准则去执行, 就会减少很多思考, 形成规律方便理解
如果心里没有一个标准, 每次开发都会觉得这样写也可以那样写也可以, 左右为难, 最后感觉只要能实现当时的需求, 完事就可以了, 不管那么多了, 最后代码就比较乱, 没有规律, 隔一段时间后自己都看不懂了.
比如一个方法究竟定义几个参数合适的问题,
1. 有人觉得语言本身又没有那么严格的限制, 我想怎样都可以
(相反的观点: 如果太多参数, 一是调用是必须按照参数顺序传输, 即使有些不用传也得传空, 二是参数越多逻辑就很有可能越复杂, 改都不敢改, 三是一些时候其实只需要其中一段逻辑但是仍然要走很多无用的判断, 甚至取出很多无用的值 )
2. 有人觉得最好只定义1个, 一个参数一个结果, 很纯粹的方法, 一看就知道需要啥
(相反的观点是: 1个参数的话方法过于简单, 能处理的逻辑有限, 必须通过多个方法去实现一个目的 )
3. 我个人觉得最好不超过两个, 参数不多记着也方便, 大概也能猜出方法是干啥的, 可以控制稍微多一些的逻辑, 但也不会太多, 阅读也方便
上边说的是单个的方法, 那么对于类的构造方法呢?
问题: 构造方法是一个类的入口, 比较特殊, 它要做一些初始化的操作, 因此很多构造方法要写很多参数
现实: 但是经常遇到的情况是, 之所以要写一个单独类, 很可能是为了把一些方法整合在一起:
1. 可能这些方法是处理同一个数据库表的, 这些方法被其他功能模块使用, 并不依赖构造方法的参数
2. 也可能是为了实现一个共同功能模块的方法的集合, 这时, 很多方法也并不依赖于构造方法的参数, 有些甚至不需要参数, 独立的可以单拎出去
构造方法的作用一般是 根据传递来的一个或几个参数, 再获取出一大堆相关的数据作为成员变量,
但不是每个成员方法都需要全部的成员变量, 如果都放在构造函数中去初始化, 难免会浪费资源
我的方案: 可以为类添加多个 setxx($foo) 方法, 这些方法每次只初始化一部分(相关的)成员变量, 而不是全部, 这样就不会浪费太多计算资源
以上是关于对开发准则的一些心得的主要内容,如果未能解决你的问题,请参考以下文章