冰浪

     今天開始做一個新的模塊，叫“時限監察”，這個模塊的功能是要對“辦件處理”的處理情況進行一個監察工作。也就是說兩者是緊密相關的。而我要做的工作就是針對辦件處理的結果或者說是記錄進行一個過濾匯總，并對有關的記錄進行處理。如某些辦件未能按時處理的，我就可以對此辦件記錄進行通知，提醒相關人員進行處理。
    首先說明一點的是，有一個VO對象，在公司的產品開發框架中是一個值對象，但這個值對象并不是簡單功能角色上的VO，而即做為數據持久化操作中與數據庫表進行對象關系映射的ORM Object，也是作用顯示層中的View Object，在這里我不討論此設計的優缺點，這不是我要說的方面。
    在辦件處理模塊，某同事已經創建了對應的VO，在這里我稱之為APVO吧，而我在時限監察模塊也需要用到它數據表中的數據，進行辦件情況的列表顯示，所以APVO對我而言是很有利用價值的，如果我能利用它，那我就需要重復創建此VO（或者說是其中大部分屬性）的工作了。對于此，我首先想到的是創建一個自己模塊的LMVO，并繼承APVO，這樣，我既可以擁有自己的私有成員，也可利用到APVO中的所需要成員屬性。如果這要求能夠實現，那么我就可減少不少工作量，而對于面向對象開發方法中也是常見的情況。
    正當我這么做時，卻發現了一個問題，APVO中的成員屬性的訪問域全是“private”類型的，這讓我大失所望，我無法繼承這些成員屬性！
    一般情況下，我們都習慣性將類成員變量的訪問域設為private類型，然后提供Setter和Getter方法，這樣的做法，我們也通常認為是比較安全的作法，是符合封裝性要求的。但這樣的做法，讓很多沒有必要進行private封裝的成員變量永遠地失去了再利用的可能。在這種情況下，如果我還是不想重寫這些成員變量的話，就只能是直接用APVO，并在其中加入我更多的成員變量，但這并不我所希望的。也許你會說，“不用繼承，可以用組合，而且組合優于繼承，不是嗎？”這句話本沒有錯，一般情況下可以這么法，而且最好這么做。但在某些情況，組合無法實現我的要求，就像在公司的開發框架中就無法進行，VO中的成員變量只能是簡單的數據類型，如String，這樣在進行數據庫操作時可以順利地對其取值和賦值，但如果組合了另一個VO對象的話，這個VO對象卻無法進行取值和賦值。
     所以，在設計類時，要考慮到類的復用，所以對其成員變量的訪問域控制上，不要一概地設成private。我們可以設為protected或者是默認訪問類型。單是這么做并不夠，我們還是要考慮安全性，也就是訪問控制。所以我們還要對其所在的包的結構進行設計。
     我們不要簡單地按功能模塊的方式來設計包，要考慮到模塊間的邏輯關系，讓有關系的模塊的包設計成“父子包”的形式，而不是按功能模塊簡單地設計成平行結構，這不利于類之間的交互，也只有這樣，我們在前面說的設計類成員變量的訪問域才變得有意義。
     如前面我提到的例子，我可以將我自己的包置于APVO所在包的子包下，再讓APVO的成員變量的訪問域聲明為protected，此時我將自己的LMVO繼承APVO，這不再行不通了！