发布：2014/7/10 16:10:05作者：管理员 来源：本站 浏览次数：1681
前面提到过helper、和libraries，主要用来存放一系列辅助函数、辅助类，用来辅助系统实现功能。但helper 和 library 之间到底有什么区别呢？什么时候该用 helper 什么时候该用 library ？这好像是个无聊的问题。。。
来谈下无聊的看法：helper里主要是一些函数， library里主要是一些类的对象。函数表示的是一种行为，类表示的是一种抽象的概念，是一系列属性和方法的集合，对象里的函数称为方法，数据则称为对象的属性。类是有状态的，而函数无状态的，所以函数与类之间最大的区别在于是否有状态，落到更实际的点就是方法与方法之间是否需要共享数据，如果需要共享数据，则可以写成类的方法，如果不需要共享数据，那就可以用写成函数。
很多时候我们会写一些静态类，每个方法都是独立的，这些方法是可以用函数来代替的，而有些时候我们需要先初始化某些参数，然后后面的方法时可以直接用到这些参数，这些不是函数所擅长的。个人相对更喜欢用类来封装，即便有时候时候没有数据的传递，但当需要传输数据时，类会更方便扩展一点。
弄清楚了这些，对 helper 和 library 的理解可能会有一点帮助。接下来谈谈该怎么用 helper 和 library。
上周分享的时候，有些同事说把业务逻辑写在helper中，来看看这样子会有什么不好。首先是很多地方都需要调用get_instance方法来获取CI实例，然后才能调用CI的方法，使用起来不不太方便。接着就是业务逻辑的易变形导致了helper中方法会更有针对性，针对特定的业务逻辑去实现，可能达不到重用的效果。可能有人会说，我会分的比较好，但我认为这种思维的规律导致了只能是业务的复用，helper函数的复用会降低。同样的library也是类似的道理，所以说不建议 helper 和 library 里调用太多的CI实例，产生的依赖越多，代码就越难复用。其实最开始也考虑过使用library来实现业务逻辑，根据文件夹来区分业务逻辑和类库，也许是因为上面的原因始终觉得不是很好，所以最终才决定增加 service 。
所以用之前需要有这样的意识，尽量减少与CI的依赖，将问题分析清楚后拆解，适合helper和library的代码才写在这里。
接下来就是PHP功力的比拼了，不管函数或者类需要遵守一个很重要的原则：单一职责， 即一个类，最好只做一件事，只有一个引起它变化的原因。如果一个函数用一句话描述不清楚，那就需要拆成多个函数；如果一个类有跟它不相干的职责，那就拆成多个类。函数应该短小精悍，如果一个函数太长，意味着关联太多，可拆分的可能性很大。编码的时候应时刻提醒自己，它是不是只做了一件事，还能不能在细分？单一职责是程序员要遵守的首要原则，然后再加上适当的说明以及参数的注释，良好的排版风格，我相信这个函数乱不到哪里去。类更复杂点，怎么样组织代码结构，怎么样更方便调用，这些需要编程知识的积累。
最后，我们可以多回头看看自己的函数或者类，从中吸取经验，让下次写的更好。
