介面版本演化引發的思考二

   介面版本演化一講解了介面如何進行演化，基本思想是當介面發生變化的時候儘可能小的對衍生類別型造成影響。某種程度上也就是對“別人”的代碼造成最小的影響。
    下面從設計模式的角度給出另外一個介面版本演化的方案，其核心是visitor模式。
該模式相信很多朋友都有瞭解。下面給出具體的實現代碼：
      

 1    public interface ITest
 2    {
 3        void Accept(ITestVisitor visitor);
 4    }
 5    public class Test1 : ITest
 6    {
 7        public void Accept(ITestVisitor visitor)
 8        {
 9            visitor.Visitor(this);
10        }
11    }
12    public class Test2 : ITest
13    {
14        public void Accept(ITestVisitor visitor)
15        {
16            visitor.Visitor(this);
17        }
18    }
19    
20    public interface ITestVisitor
21    {
22        void Visitor(Test1 test1);
23        void Visitor(Test2 test2);
24    }
25    public class TestVisitor : ITestVisitor
26    {
27        public void Visitor(Test1 test1)
28        {
29        }
30        public void Visitor(Test2 test2)
31        {
32        }
33    }

   如上，Test類型增加新的服務轉嫁為visitor類型增加一個新的擴充類型，符合開閉原則，是個不錯的設計方案。該方案的缺點我總結了下：
 

1． 原體系必須能夠增加accept方法。

2． Visitor有可能沒有足夠的資訊（從原體系擷取的）來完成動態增加的方法。

3.    原體系發生變化，訪問體系也要發生變化。
    可以看到，沒有完美的解決方案。這也就是軟體設計的魅力所在，一切都是需求驅動。