系统中循环引用

系统中循环引用

系统中存在循环引用的坏处

public class A{
        private B b;
        public void methodA(){
            //dosomthing
            b.methodA();
            //dosomthing
        }
        public void methodB(){
    
        }    
        }
    public class B{
        private A a;
        public void methodA(){
        
        }
        public void methodB(){
            //dosomthing
            a.methodB();
        //dosomthing
        }
    }

从直观上来看,类A中耦合了类B,从程序的角度上看,假如类A的methodB()方法作了修改,就会致使类B的methodB作出相应的修改, 而且还会致使一系列调用B.methodB()的方法也改变；另外一方便若是类B的methodA()作出修改也会致使类A产生相同的反作用.

是否能够避免循环引用的出现

(Service层自己根据不一样的业务职责是能够分红多个层，只要确保在同一层里面的Service不会互相引用（也不该该引用），复杂的业务需求应当由更上层的Service提供)　　　这个思路主要是,同层是不能依赖的,由于存在依赖确定就会致使相互依赖。若是两个类存在相互依赖,能够产生一个第三者同事依赖这两个类来解决两个类的相互的依赖关系,可是这是一种很理想的状况,实际上若是作到这样,容易整个系统的抽象层次就会变得无比的多,会加大系统的复杂度

public Class DaoA{
    pubic void queryStudent();
}
public Class ServiceA{
    pubic void queryStudent(){
    //dosomething
    //DaoA.queryStudent();
    //dosomething
    }
}
public Class DaoB{
    pubic void insetStudent();
    public void updateStudent();
}
public Class ServiceB{
    pubic void insetStudent(){
        ServiceA.queryStudent();
        DaoB.insetStudent();
    }
    pubic void updateStudent(){
        //dosomething
        DaoB.updateStudent();
        //dosomething
    }
}

ServiceA是对学生查询业务的一个抽象,ServiceB是对学生新增业务的一个抽象。而且因为业务要求,在新增学生的时候必需要先查询学生是否存在,由于ServiceA.queryStudent()里面已经封装了查询业务,因此直接调用该方法就好了.可是由于同层之间不能相互引用,因此必须出现第一个第三者,同时修改ServiceB的方法

public Class ServiceB{
        pubic void insetStudent(){
            DaoB.insetStudent();
        }
    }

    public Class ServiceC(){
        pubic void insetStudent(){
            ServiceA.queryStudent();
            ServiceB.insetStudent();
        }
    }

因此在service上面又加了一层,必然系统的复杂度就上来了因此个人想法是:同层次是容许相互依赖的

哪一层才容许相互依赖

若是出现相互依赖的层次越底层,那么由1引发的反作用对系统的影响就越大。从大的SOA架构上来看的话底层的原子服务是不能相互依赖的,到了上层的组合服务层,是容许相互依赖的;对于某一个原子服务,Dao层是不容许相互依赖的,可是service是容许相互依赖的

后记

1. ServiceA.queryStudent()这一层封装的由来
   ServiceB固然能够没必要依赖ServiceA,只须要把ServiceA.queryStudent()里面的方法直接copy一份,直接依赖DaoA.可是若是系统其它地方也须要用到这个queryStudent逻辑,那么它也只能再copy一份,因此为了提升代码的复用性在ServiceA中抽象一个queryStudent方法(固然没必要等到不少场景下须要这一个query逻辑才抽象queryStudent方法,ServiceA自己能够根据自身的业务提早抽象)

2. 合理的抽象层次
   和1同样,当发现不少场景须要同时调用ServiceB.insetStudent和ServiceB.updateStudent方法完成本身的业务,由于在不少时候ServiceB就是一个RPC服务了,因此为了性能考虑,就须要把insetStudent和updateStudent方法统一成一个方法,刚开始这一层模块内部的组合服务层是很薄的,没有必要独立出去,随着业务场景的增长组合借接口就会慢慢增多,这个时候就能够把这些模块内部的组合服务单独抽象,它的抽象层次是比原来的service是要高一层,而且能够单独部署和发布