今天在改造管理端代码的时候，遇到了一些问题，也找到了一些技巧，在这里记录下，备忘~~~
首先是关于代码编写规范的一点感悟
1.定义类、及方法时尽量采用懒惰的复用式设计，这在设计之初可能看不出什么优势，但当你需要对系统整体添加一个功能组件时，而这个功能组件需要覆盖到系统原来的所有功能模块时，你会发现这种设计带来的便利，你不用苦逼的为每一个功能进行整容手术，因为设计的最基本原则是扩展时能尽量避免“家喻户晓”
干巴巴的说，可能不明所以，以备自己以后再看的时候不知自己所云，特在此留实例
现有一邮件系统管理端，采用面向过程式设计，每个功能点，各自为战，系统一共30-40功能点，代码经由3-4个人编写完成，由于没有统一的编码规范，导致各个功能模块的风格各具特色，现由于市场需要，要对系统管理端功能进行一个审批功能的添加，要实现对每个功能模块都可以单独的进行审批开关控制，这就遇到了一个难题，这个管理系统架构采用面向过程式设计，这种设计本身就为纵向添加功能设置了障碍，无法统一管理，必须各个coding，这会导致很大的工作量，也导致了系统的不稳定性，系统可扩展性基本为零，只能是功能的叠加，由于工期需要，时间不允许对系统架构进行重新设计，只能想办法在原有系统上实现此功能，无奈之举，最后找了个折中的办法，在所有的功能的module层上对功能类进行抽象类继承，对类方法加过滤层，过滤层实现有点小卑鄙，就是将原来的方法加下划线，在新建个同名的方法，参数也与原来方法一样，在这个方法中进行审批功能的添加，将原有类及调用方法，以及方法参数都存储到数据库中，审批通过时再从数据库中取出相应信息，重新组成代码，调用原始方法进行之下的正常功能流程。这个方法很龌龊，但项目工期需要，只能这么干，自己先鄙视下这个系统设计者，自己在改造这个管理端时遇到很多阻碍，深受不同编码风格之害，首先各个类定义各种各样，增删改查方法名各不相同，参数五花八门，有一个方法参数为一个数组，有的为条件+数组，有的干脆是条件罗列，很难让人偷懒写个复用的方法，狠狠鄙视下coding者~给自己到处挖坑
总结几点，一个系统在代码设计上一定要风格统一，特别是团队开发中，一定要保持代码的透明，同质性，不管用面相对象还是面相过程，都要保证同级功能代码的一致性，可复用性，同时多考虑可扩展性，谁也不能保证设计出来的架构会一成不变，注意扩展性，会对以后的工作提供很大的便利性
数据库表文件，尽量采用配置文件形式调用，不要再类中直接写表名，以备以后表结构变动，给系统造成隐患
裙带功能尽量提供一个统一的入口，我所指的裙带功能是一个模块功能可能涉及到其他模块数据变动的，尽量保证功能代码的原子性，写的太散，很难统一控制
2.今天在找解决办法的时候用到了一个组合php __autoload()&call_user_func_array()
__autoload()方法大家都清楚就不多介绍了，下面总结下call_user_func_array方法的使用，今天多亏了这个办法，才解了我的燃眉之急，下面记录下我遇到的状况：
我要将操作的类、方法及参数都存放到数据库中，等待管理员审批通过后再调用相应类的相应方法，将相应参数传递回去，由于编码风格的不规范，导致方法名没有规律、参数多少不定，这可把我难坏了，后来在网上就看到了这个神器call_user_func_array，真是瞌睡时送来了个枕头，这个方法很强大，不仅能调用普通文件的普通方法，还可以调用类中的方法，参数多少不限，以数组形式组合传递，官方解释 Call a user function given with an array of parameters，这样我就将每次调用操作都以json数据形式存储在数据库，数据格式为array(class=>'',func=>'',params=>array('count'=>3,'arg0'=>'','arg1'=>'','arg2'=>'')),调用的时候call_user_func_array(array($class,'function'),array(params))很给力
在这里提醒注意下，一般这里调用类方法时不用实例化可以直接调用，但是如果方法体中有$this调用，就必须实例化后再用此方法了，这是一点经验~