僅包含私有成員的Java類

Question

最近我遇到了一種需要為我的Android應用程序創建自定義VideoView的情況。 我需要訪問MediaPlayer對象並添加一些監聽器。

不幸的是（對我來說），VideoView類的所有成員都是私有的，所以即使擴展這個類也無法幫助我獲得對其MediaPlayer對象（或其他任何東西）的訪問權限，我不得不用我的完整復制類。修改。

好吧，雖然這聽起來像是在為“艱苦的工作”而抱怨，但在這種情況下擴展課程比較容易（因為所有的資源都可以使用......），但這讓我真的懷疑這種信息方法躲了起來。 這是一種比將主要組件留給修改/訪問（受保護，而不是公共）更好的做法嗎？ 我的意思是，我明白如果我擴展VideoView類，有一天他們可能會在VideoView類中改變一些東西而且我可能會遇到麻煩，但是如果他們改變了類，我自己的（重復）版本會有更大的差異來自VideoView類， 我的目標不是創建自己的視頻視圖，而是擴展可用的VideoView。

Answer 1

在這種情況下，我通常更喜歡構圖而不是繼承。

編輯：
當子類和超類都在同一個程序員的控制下時，使用繼承是安全的，但實現繼承可能導致脆弱的API。 正如你所提到的，如果超類實現發生了變化，那么子類可能會破壞或者更糟糕 - 會無聲地執行非預期的事情。

另一種方法是使私有字段引用稱為組合的現有類（VideoView）的實例，並且新類中的每個實例方法都在現有類的包含實例上調用相應的方法並返回結果。 這種包裝方法也可稱為“裝飾器”模式

Answer 2

當一個程序員把某些東西私有化時，他們會打賭沒有其他人需要使用或覆蓋它，所以從信息隱藏中獲得回報。 有時賭注不會下降。 他們是休息。

Answer 3

我不能代表特定VideoView開發人員的推理，但如果您正在開發API，並確定某些數據所代表的狀態需要始終遵循某些規則，以維護對象的完整性和預期目的，那么將成員vars設為私有是有意義的，這樣你就可以控制它們的修改。

它確實限制了其他開發者可以做的事情，但我認為這是重點。 有些事情，如果要改變它們，您會希望它在具有API治理的組中進行討論和驗證。 在這種情況下，私有化是有意義的，這樣對它的修改就不會在集團的監督之外失控。

我不知道有一個靜態的經驗法則決定什么時候需要屬於這個類別，但在某些情況下我肯定能看到它的使用。

Answer 4

當我閱讀所有啟發性答案（和評論）並評論那些我意識到我期望某些與某些課程無關的東西時。 在VideoView示例中，此類已經是繼承鏈中的最后一個。 它不應該被擴展，因為它是一個邏輯單元，非常具體而且非常緊湊，用於非常特定的目的。 我需要從視圖和MediaPlayer獲得特殊狀態，這是QC目的的需要，在提供一個封閉單元的產品時（盡管源是開放的），實際上不應該考慮這些需求。 這是一個合理的論據，我覺得它很令人滿意。 有時不是每個 OOP概念都應該實現。 謝謝大家的回復。