維護兩個列表
  　　因為我們要改變對象的填充顏色以實現 Change fill to hot pink 按鈕，因此維護了兩個可繪制對象列表：一個列表是全部對象，另一個列表是可填充對象。我們為這兩個列表都使用了 ArrayList 類。ArrayList 對象包含一組 Object 引用 -- 這樣一個 ArrayList 可以包含系統中任何類型的混合。
  
  　　這實際上并沒有什么幫助 -- 我們希望 ArrayList 僅僅包括可繪制/可填充對象。為此，我們將 ArrayList 對象設為私有；然后將向列表添加對象的過程設為一個方法，該方法只接受一個 DShape。
  
  　　當使用 Add 方法向列表中添加對象時，我們將所有對象添加到 wholeList 中，然后檢查對象是否還應添加到 filledList 集合中。
  
  　　請記住，Add 方法（以及列表）具有類型安全特性：它只接受 DShape（或者從 DShape 派生的類型，例如我們在上面創建的所有類型）。您不能將整數或字符串添加到列表中，這樣我們便可以知道這個列表只包含可繪制對象。能夠確知這一點是很方便的！
  
  　　繪制項
  
  　　我們還有一個 DrawList 方法，用于在它作為參數傳遞的 Graphics 對象上繪制列表中的對象。此方法具有兩種情況：如果列表為空，它繪制一個字符串，說明列表為空。如果列表不為空，它使用一個 for each 構造函數遍歷該列表，并在每個對象上調用 Draw。實際的遍歷和繪圖代碼再簡單不過了，如下面的 Visual Basic 所示。
  
  
  　　Visual Basic
  .NET Dim d As DShape
  For Each d In wholeList
  d.Draw(g)
  Next
  
  
  　　C# 代碼幾乎完全相同（當然，其行數更少）。
  
  
  　　C#
  foreach (DShape d in wholeList)
  d.Draw(g);
  
  
  　　由于列表是封裝的，我們知道它具有類型安全特性，因此可以僅調用 Draw 方法而不必檢查對象的類型。
  
  　　返回可填充列表
  　　最后，我們的 Change fills to hot pink（將填充色更改為粉紅）按鈕需要一個對所有可填充對象的引用數組，以便更改其 FillBrushColor 屬性。雖然可以編寫一個方法遍歷列表并將顏色更改為傳入的值，但這一次 Dr. GUI 選擇了返回一個對象引用數組。幸運的是，ArrayList 類具有一個 ToArray 方法，利用它可以創建一個傳遞數組。該方法獲取我們需要的數組元素類型 -- 從而可以傳遞回所需的類型 -- IFillable 數組。
  
  
  　　C#
  
  public IFillable[] GetFilledList() {
  return (IFillable[])filledList.ToArray(typeof(IFillable));
  }
  
  　　Visual Basic
  
  .NET Public Function GetFilledList() As IFillable()
  Return filledList.ToArray(GetType(IFillable))
  End Function
  
  
  　　在兩種語言中，我們都使用了一個內置運算符獲取給定類型的 Type 對象 -- 在 C# 中，是 typeof(IFillable)；在 Visual Basic 中，是 GetType(IFillable)。
  
  　　調用程序使用此數組在可填充對象引用數組中遍歷。例如，將填充顏色更改為粉紅的 Visual Basic 代碼如下所示：
  
  
  Dim filledList As IFillable() = drawingList.GetFilledList()
  Dim i As IFillable
  For Each i In filledList
  i.FillBrushColor = Color.HotPink
  Next
  
  　　用于分解出公共代碼的 Helper 方法和類
  　　您可能注意到，Draw 和 Fill 方法有很多共同的代碼。確切地說，每個類中創建筆或畫筆的代碼、建立 Try/Finally 塊的代碼以及清理筆或畫筆的代碼都是相同的 -- 唯一的區別是進行繪圖或填充時調用的實際方法。（由于 C# 中 using 語法非常簡潔，因而多余代碼的數量并不明顯。）在 Visual Basic .NET 中，每五行代碼中可能有一行特殊的代碼在所有實現中都是相同的。
  
  　　總之，如果存在大量重復代碼，就需要尋求分解出公共的代碼，以便形成為所有類所共享的公共子例程。這類方法有很多，Dr. GUI 非常高興為您展示其中的兩種。第一種方法僅用于類，第二種方法可用于類或接口，在本例中只用于接口。
  
  　　方法 1：公共入口點調用虛擬方法
  　　在第一個方法中，我們利用了類（不同于接口）可以包含代碼這一事實。所以我們提供了一個用于創建筆的 Draw 方法的實現，以及一個異常處理程序和 Dispose，然后調用實際進行繪圖的 abstract/MustOverride 方法。確切地說，我們更改了 DShapes 類以適應新的 Draw 方法，然后聲明了新的 JustDraw 方法：
  
  
  Public MustInherit Class DShape
  ' Draw 不是虛擬的，這似乎有些不尋常……
  ' Draw 本應是抽象的 (MustOverride)。
  ' 但此方法是繪圖的框架，而不是繪圖代碼本身，
  ' 繪圖代碼在 JustDraw 中完成。
  ' 還請注意，這意味著同原版本相比，這些類具有
  ' 不同的接口，雖然它們完成的工作相同。
  Public Sub Draw(ByVal g As Graphics)
  Dim p = New Pen(penColor)
  Try
  JustDraw(g, p)
  Finally
  p.Dispose()
  End Try
  End Sub
  ' 這里是需要成為多態的部分 -- 因此是抽象的
  Protected MustOverride Sub JustDraw(ByVal g As Graphics, _
  ByVal p As Pen)
  Protected bounding As Rectangle
  Protected penColor As Color ' 還應具有屬性
  ' 還應具有移動、調整大小等方法。
  End Class
  
  　　一個值得注意的有趣的地方：Draw 方法并不是 virtual/Overridable。因為所有派生類都將以相同的方式完成這部分繪圖（如果在 Graphics 上繪圖 [如本例中的定義]，則必須指派并清理筆），因此它不需要是 virtual/Overridable。
  
  　　實際上，Dr. GUI 認為在本例中，Draw 不應該是 virtual/Overridable。如果確實要覆蓋 Draw 的行為（而不僅是 JustDraw 的行為），則可以將它設置為 virtual/Overridable。但在本例中，沒有理由覆蓋 Draw 的行為，如果鼓勵程序員進行覆蓋還會帶來隱患 -- 他們可能不會正確處理筆，或者使用其他方法繪制對象而不是調用 JustDraw，這就違反了我們內置到類中的假設。因此，將 Draw 設置為非虛擬（順便說一下，在 Brand J 中沒有這個選項）可能會降低代碼的靈活性，但會更加可靠 -- Dr. GUI 認為在本例中，這樣做非常值得。
  
  　　JustDraw 的典型實現如下所示：
  
  
  Protected Overrides Sub JustDraw(ByVal g As Graphics, ByVal p As Pen)
  g.DrawEllipse(p, bounding)
  End Sub
  
  　　如您所見，我們獲得了所希望的簡潔的派生類實現。（可填充類中的實現只是略微復雜一些 -- 稍后會看到。）
  
  　　請注意，我們在接口中添加了一個額外的公開方法 JustDraw，除了要繪制的 Graphics 對象外，該方法還引用我們在 Draw 中創建的 Pen 對象。因為該方法需要是 abstract/MustOverride，因此必須是公開的。
  
  　　這并不是一個大問題，但它確實更改了類的公開接口。所以即使這個分解出公共代碼的方法非常簡單方便，也應當盡可能選擇其他方法以避免更改公開接口。
  
  　　方法 2：虛擬方法調用公共 helper 方法，使用回調
  　　在實現接口的 Fill 方法時，代碼的復雜程度也很類似：每六行代碼中可能有一行特殊的代碼在所有實現中都是相同的。但是我們不能將公共的實現放到接口中，因為接口只是聲明，它們不包含代碼或數據。此外，上面列出的方法是不能接受的，因為它會更改接口 -- 我們可能并不希望這樣，或者因為是其他人創建的接口，我們根本不可能更改！
  
  　　所以，我們需要編寫一個 helper 方法以設置并回調我們的類，以便進行實際的填充。對于本例，Dr. GUI 將代碼放在一個單獨的類中，這樣任何類都可以使用該代碼。（如果采用該方法來實現 Draw，則可以將 helper 方法作為抽象基類中的私有方法實現。）
  
  　　暫時不進一步展開，以下是我們創建的類：
  
  
  ' 請注意，該 delegate 提供的幫助仍然具有多態行為。
  Class FillHelper
  Public Delegate Sub Filler(ByVal g As Graphics, ByVal b As Brush)
  Shared Sub SafeFill(ByVal i As IFillable, ByVal g As Graphics, _
  ByVal f As Filler)
  Dim b = New SolidBrush(i.FillBrushColor)
  Try
  f(g, b)
  Finally
  b.dispose()
  End Try
  End Sub
  End Class
  
  　　我們的 helper 方法調用了 SafeFill，該方法接受一個可填充對象（請注意，這里我們使用了 IFillable 接口類型，而不是 DShape，從而只能傳遞可填充對象）、一個要在其上進行繪圖的 Graphics 和一個稱為 delegate 的私有變量。我們可以將 delegate 視為一個對方法（而不是對象）的引用 -- 如果您經常使用 C 或 C++ 編程，則可以將其視為具有類型安全特性的函數指針。可以將 delegate 設置為指向任何具有相同參數類型和返回值的方法，無論是實例方法還是 static/Shared 方法。將 delegate 設置為指向相應的方法后（例如在調用 SafeFill 時），我們可以通過 delegate 間接調用該方法。（順便說一下，Brand J 中沒有 delegate，這時如果使用此方法，會非常困難并且很不靈活）。
  
  　　delegate 類型 Filler 的聲明位于類聲明之上 -- 它被聲明為一個不返回任何內容（在 Visual Basic .NET 中是一個 Sub）并且將 Graphics 和 Brush 作為參數傳遞的方法。我們會在將來的專欄中深入討論 delegate。
  
  　　SafeFill 的操作非常簡單：它指派畫筆并將 Try/Finally 和 Dispose 設置為公共代碼。它通過調用我們作為參數接收的 delegate 所引用的方法進行各種操作：f(g, b)。
  
  　　要使用這個類，需要向可填充對象類中添加一個可以通過 delegate 調用的方法，并確保將該方法的引用（地址）傳遞到 SafeFill，我們將在接口的 Fill 實現中調用 SafeFill。以下是 DFilledCircle 的代碼：
  
  
  Public Sub Fill(ByVal g As Graphics) Implements IFillable.Fill
  FillHelper.SafeFill(Me, g, AddressOf JustFill)
  End Sub
  Private Sub JustFill(ByVal g As Graphics, ByVal b As Brush)
  g.FillEllipse(b, bounding)
  End Sub
  
  　　這樣，當需要填充對象時，便在該對象上調用 IFillable.Fill。它將調用我們的 Fill 方法，而 Fill 方法調用 FillHelper.SafeFill，后者傳遞一個對我們的可填充對象的引用、所傳遞的要在其上進行繪圖的 Graphics 對象以及一個對實際完成填充的方法的引用 -- 在本例中，該方法是私有的 JustFill 方法。
  
  　　然后，SafeFill 通過 delegate -- JustFill 方法來設置畫筆和調用，JustFill 方法通過調用 Graphics.FillEllipse 進行填充并返回值。SafeFill 將清理畫筆并返回到 Fill，Fill 再返回到調用者。
  
  　　最后是 JustDraw，它和原始版本中的 Draw 很類似，因為我們都調用了 Fill，并調用了基類的 Draw 方法（這是我們以前所做的）。以下是相關代碼：
  
  
  Protected Overrides Sub JustDraw(ByVal g As Graphics, ByVal p As Pen)
  Fill(g)
  MyBase.JustDraw(g, p)
  End Sub
  
  　　請記住，指派畫筆和筆的復雜之處在于它在 helper 函數中的處理 -- 在 Draw 中，它位于基類中；在 Fill 中，它位于 helper 類中。
  
  　　如果您認為這比以前復雜了，那么確實如此。如果您認為由于額外的調用和需要處理 delegate，速度比以前緩慢了，也確實如此。在生活中總是有很多東西需要進行權衡。
  
  　　那么，這樣做值得嗎？也許值得。這取決于公共代碼的復雜程度，以及該代碼需要重復的次數。也就是說，需要權衡。如果我們決定刪除 Try/Finally，而只在完成繪圖后清理筆和畫筆，代碼便會非常簡單，這些方法也就用不上。并且在 C# 中，using 語句非常簡潔，我們也不必費神使用這些方法。Dr. GUI 認為，在 Visual Basic 中使用 Try/Finally 時，可以使用、也可以不使用這些方法，這里旨在向大家展示這些方法，以便在遇到具有大量公共代碼的情況時使用。