rt请各位结合PHP开发项目的整体架构来考虑mysqlphp

解决方案 »

  1.   

    原则一:如果类A 和类B 毫不相关,不可以为了使B 的功能更多些而让B 继承A 的功能
    原则二:如果类B 有必要使用A 的功能,则要分两种情况考虑
    a、若在逻辑上B 是A 的“一种”(a kind of ),则允许B 继承A 的功能。
    b、若在逻辑上A 是B 的“一部分”(a part of),则不允许B 继承A 的功能,而是要用A和其它东西组合出B。
      

  2.   

    那么可不可以用interface,abstract或traits之类的呢?而且如果用组合的话可不可以用延迟静态绑定呢?
      

  3.   

    interface 接口,这就是为组合而设的。使得不同的类具有相同的界面
    abstract 抽象,这是为继承而设的。强制共有方法的实现
    traits 特征,这是为方便代码复用而设的。php的类的方法声明需在类中实现,导致类定义代码可读性变差。引入 traits 使得可读性增强
      

  4.   

    进来跟老徐学习一下。log类 我写过,不过不记得自己思考过这么高深的话题...
    我发现自己最近越来越只有过程没有对象了,轮子也越做越多...
      

  5.   

    阵时不能理解设计LOG类会涉及哪些困难的问题。。
    我现在的简单程序也涉及一些LOG,一个简单的log类然后一个便捷的记录方法,以参数形式描述日志级别和具体类型,再加一条msg消息字符串就成了日志。那么看来你们讨论的是高级的LOG咯。继续围观此帖。
      

  6.   

    如果有多种log的话,直接想到的就是简单的继承(组合?组合模式吗?为啥会想到这个呢莫非各种日志之间还能有结构关系?)即公共的方法父类写一写,各种日志个性的方法子类继承重写下,当做不同的日志策略writer类。往深了想想,可以有个日志管理器,由他全权接收写日志的请求,在内部通过策略模式,调用不同的日志writer去curd。再往深了想想,查询日志的条件是否会不一样呢?所以,也许在日志管理器之前还需要有个预处理参数的一套设计,比如有的日志有用户查询,需要过滤用户;有的日志需要限制应用,需要过滤应用等等。如果这种要求比较多,这部分单拿出来写是很有必要的,也可以考虑装饰模式。再往深了想想,如果日志本身包括不同的格式或内容,也可以通过装饰模式写不同的格式方案,在不同的writer中调用进行格式排版。以上,就是个闲的蛋疼的2货的过渡设计,反正我没这么干目的简单,就写简单点,写个父类,每个写个子类,或者就简单switch case一下都行了。主要还是按需设计