摘要：系統(tǒng)中循環(huán)引用系統(tǒng)中存在循環(huán)引用的壞處從直觀上來看類中耦合了類從程序的角度上看假如類的方法做了修改就會(huì)導(dǎo)致類的做出相應(yīng)的修改并且還會(huì)導(dǎo)致一系列調(diào)用的方法也改變另一方便如果類的做出修改也會(huì)導(dǎo)致類產(chǎn)生相同的副作用是否可以避免循環(huán)引用的出現(xiàn)層本身

    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()方法做了修改,就會(huì)導(dǎo)致類B的methodB做出相應(yīng)的修改, 并且還會(huì)導(dǎo)致一系列調(diào)用B.methodB()的方法也改變；另一方便如果類B的methodA()做出修改也會(huì)導(dǎo)致類A產(chǎn)生相同的副作用.

(Service層本身根據(jù)不同的業(yè)務(wù)職責(zé)是可以分成多個(gè)層，只要確保在同一層里面的Service不會(huì)互相引用（也不應(yīng)該引用），復(fù)雜的業(yè)務(wù)需求應(yīng)當(dāng)由更上層的Service提供)　　　這個(gè)思路主要是,同層是不能依賴的,因?yàn)榇嬖谝蕾嚳隙ň蜁?huì)導(dǎo)致相互依賴。如果兩個(gè)類存在相互依賴,可以產(chǎn)生一個(gè)第三者同事依賴這兩個(gè)類來解決兩個(gè)類的相互的依賴關(guān)系,但是這是一種很理想的情況,實(shí)際上如果做到這樣,容易整個(gè)系統(tǒng)的抽象層次就會(huì)變得無比的多,會(huì)加大系統(tǒng)的復(fù)雜度

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是對(duì)學(xué)生查詢業(yè)務(wù)的一個(gè)抽象,ServiceB是對(duì)學(xué)生新增業(yè)務(wù)的一個(gè)抽象。并且由于業(yè)務(wù)要求,在新增學(xué)生的時(shí)候必須要先查詢學(xué)生是否存在,因?yàn)?b>ServiceA.queryStudent()里面已經(jīng)封裝了查詢業(yè)務(wù),所以直接調(diào)用該方法就行了.但是因?yàn)橥瑢又g不能相互引用,所以必須出現(xiàn)第一個(gè)第三者,同時(shí)修改ServiceB的方法

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

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

所以在service上面又加了一層,必然系統(tǒng)的復(fù)雜度就上來了所以我的想法是:同層次是允許相互依賴的

如果出現(xiàn)相互依賴的層次越底層,那么由1引起的副作用對(duì)系統(tǒng)的影響就越大。從大的SOA架構(gòu)上來看的話底層的原子服務(wù)是不能相互依賴的,到了上層的組合服務(wù)層,是允許相互依賴的;對(duì)于某一個(gè)原子服務(wù),Dao層是不允許相互依賴的,但是service是允許相互依賴的

ServiceA.queryStudent()這一層封裝的由來
ServiceB當(dāng)然可以不必依賴ServiceA,只需要把ServiceA.queryStudent()里面的方法直接copy一份,直接依賴DaoA.但是如果系統(tǒng)其它地方也需要用到這個(gè)queryStudent邏輯,那么它也只能再copy一份,所以為了提高代碼的復(fù)用性在ServiceA中抽象一個(gè)queryStudent方法(當(dāng)然不必等到很多場景下需要這一個(gè)query邏輯才抽象queryStudent方法,ServiceA本身可以根據(jù)自身的業(yè)務(wù)提前抽象)

合理的抽象層次
和1一樣,當(dāng)發(fā)現(xiàn)很多場景需要同時(shí)調(diào)用ServiceB.insetStudent和ServiceB.updateStudent方法完成自己的業(yè)務(wù),因?yàn)樵诤芏鄷r(shí)候ServiceB就是一個(gè)RPC服務(wù)了,所以為了性能考慮,就需要把insetStudent和updateStudent方法統(tǒng)一成一個(gè)方法,剛開始這一層模塊內(nèi)部的組合服務(wù)層是很薄的,沒有必要獨(dú)立出去,隨著業(yè)務(wù)場景的增加組合借接口就會(huì)慢慢增多,這個(gè)時(shí)候就可以把這些模塊內(nèi)部的組合服務(wù)多帶帶抽象,它的抽象層次是比原來的service是要高一層,并且可以多帶帶部署和發(fā)布