摘要：系統(tǒng)中循環(huán)引用系統(tǒng)中存在循環(huán)引用的壞處從直觀上來看類中耦合了類從程序的角度上看假如類的方法做了修改就會導(dǎo)致類的做出相應(yīng)的修改并且還會導(dǎo)致一系列調(diào)用的方法也改變另一方便如果類的做出修改也會導(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()方法做了修改,就會導(dǎo)致類B的methodB做出相應(yīng)的修改, 并且還會導(dǎo)致一系列調(diào)用B.methodB()的方法也改變；另一方便如果類B的methodA()做出修改也會導(dǎo)致類A產(chǎn)生相同的副作用.

(Service層本身根據(jù)不同的業(yè)務(wù)職責(zé)是可以分成多個層，只要確保在同一層里面的Service不會互相引用（也不應(yīng)該引用），復(fù)雜的業(yè)務(wù)需求應(yīng)當(dāng)由更上層的Service提供)　　　這個思路主要是,同層是不能依賴的,因為存在依賴肯定就會導(dǎo)致相互依賴。如果兩個類存在相互依賴,可以產(chǎn)生一個第三者同事依賴這兩個類來解決兩個類的相互的依賴關(guān)系,但是這是一種很理想的情況,實際上如果做到這樣,容易整個系統(tǒng)的抽象層次就會變得無比的多,會加大系統(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是對學(xué)生查詢業(yè)務(wù)的一個抽象,ServiceB是對學(xué)生新增業(yè)務(wù)的一個抽象。并且由于業(yè)務(wù)要求,在新增學(xué)生的時候必須要先查詢學(xué)生是否存在,因為ServiceA.queryStudent()里面已經(jīng)封裝了查詢業(yè)務(wù),所以直接調(diào)用該方法就行了.但是因為同層之間不能相互引用,所以必須出現(xiàn)第一個第三者,同時修改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引起的副作用對系統(tǒng)的影響就越大。從大的SOA架構(gòu)上來看的話底層的原子服務(wù)是不能相互依賴的,到了上層的組合服務(wù)層,是允許相互依賴的;對于某一個原子服務(wù),Dao層是不允許相互依賴的,但是service是允許相互依賴的

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

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