CSV ファイルがあり、CsvFileから拡張するという名前のクラスを作成するとしjava.io.Fileます。このクラスは、CSV ファイルを解析し、ファイル内の列数などのデータを返すことができます。入力として受け取る関数にも使用できjava.io.Fileます。F のようにileUtils.copyFile(File from, File to)。
私の同僚は、私が継承からあまりにも多くを公開していると考えています。彼のアイデアは、java.io.Fileそれを継承するのではなく、プライベート プロパティに保持することでラップすることです。彼は、ファイルからすべてのパブリック メソッド/プロパティを公開するとカプセル化が解除されると考えていますが、すべての関数java.io.Fileを無料で取得できるため、私はそれを利点と考えています。
どう思いますか？
私はむしろあなたの同僚に同意したいと思います: 継承すると、、、 などのオブジェクトにjava.util.File適用できないメソッドが公開されます。CsvFilelist()listFiles()setExecutable()
getterjava.util.Fileの背後にあるプロパティを作成することは、より良い選択のように思えます。これにより、クラスのユーザーに無関係な操作が明らかにならず、選択した基本クラスから継承できます。
それはすべて、クラスの目的によると思います。あなたが本当に行動を拡張しようとしているなら、それは理にかなっていると思います。File の動作を拡張するのではなく、CSV オブジェクトを作成するだけの場合、カプセル化によってその動作が意図したものだけに制限されます。
また、ファイルシステムに送信できない (または簡単に送信できない) さまざまなソースから CSV 形式の InputStream または Reader を受け入れることができるように、より汎用的にすることを検討することもできます。便宜上、java.io.File セッター/コンストラクターを引き続き使用できます。
これは実際には素晴らしい議論です。あなたの同僚は、この歴史の右側にいます。一般に、継承の問題は、is-a と has-a の関係に帰着します。一般に、継承より合成を使用する方が柔軟です。あなたの場合、危機一髪です。やはりcsvファイルはファイルです。csvfile has-a file と言うのは正しく聞こえません。同様に考えられるのは、継承を行うことですが、継承されたファイルをラップして、必要な CSV ファイルメソッドのみが公開されるようにすることです。また、A から継承したいが、より制限されたインターフェイスを世界に公開したい、この周りのいくつかの設計パターンも調べます。これには設計パターンがあるとほぼ確信しています。名前しか思い出せない……。
「どちらでもないと思いますが、両方を組み合わせることが道です。ホイールがその目的を果たすようにカプセル化するパターンよりも、ホイールが再発明されないように最初に継承します。」
同僚が言及しているアプローチには、本当に必要なメソッドのみを公開することで API が非常に小さくなるという利点もあります。これにより、クラスの使用方法がユーザーに明確になります (パブリック API はある種のドキュメントと考えることができます)。 .
あなたの質問に関して
継承はカプセル化を破りますか?
次に、Joshua Bloch の「Effective Java」によると、継承は常にカプセル化を破ります。
メソッド呼び出しとは異なり、継承はカプセル化に違反します [Snyder86]。つまり、サブクラスは、その適切な機能について、そのスーパークラスの実装の詳細に依存します。
継承と合成のどちらを使用するかについては、すでに多くの人が言っているようにCsvFile、ファイルであるかどうかによって異なりますjava.util.File。
私の見方は自由すぎるかもしれませんが... カプセル化と継承には理由があります。(アセンブラーから高水準言語への「進化」を見てください。) その理由はプログラマーです。より高いレベルの抽象化/パラダイムを使用すると、より優れたコードを記述できます。もちろん、トリックは「より良い」を定義することです。私にとって、これは保守性、自己文書化、およびコードの再利用です。そのため、特定のケースでは、継承よりもカプセル化を選択します。たぶん、一度書くのは少し面倒かもしれませんが、将来維持するのはずっと簡単です。(もちろん、この CSV はより大きなプロジェクトの一部であると仮定します。)