私はJTableを使用するスイングベースのアプリケーションを実行しています。コンボボックスの選択が必要な列の1つにDefaultCellEditorを使用しました。しかしDefaultCellEditorには私が必要としない多くの方法があります。だから私は必要なメソッドだけを実装したAbstractCellEditorを拡張してカスタムCellEditorを書いた。私の質問はJavaクラスのサイズはアプリケーションのパフォーマンスに影響しますか
（一般的には）私たちがクラスを持っていて、そのクラスのすべてのメソッドを必要としないなら、それを使うのはいいですか、それともそれらのメソッドだけを実装するカスタムクラスを書くのが良いですか？我々は必要としている？
カスタムクラスを使用すると、アプリケーションのパフォーマンス（メモリ）が改善されるか、すべてのメソッドを持つクラスと同じになりますか？
ご協力いただければ幸いです。
JDK自体を含むアプリケーション内の他のものがDefaultCellEditor,を使用していると信じていない限り、あなたは事態を活発に悪化させることでほぼ間違いなく時間を無駄にしています。
典型的なJVMSが実行するギガバイトを使用する極端なケースでは、多分100kのコードを保存した可能性があることを考慮する必要もあります。だから、0.01％のコードスペースを節約しているかもしれません。これは時間の生産的な使用ではありません。正しい手順は、時間と空間のボトルネックが実際にどこにあるのかをテストして測定することです。プログラマーは、これらのことを予言することで悪名高く知られています。
+1。 'DefaultCellEditor'を使ってください。あなたはそれがうまくいくと知っているので、あなたはバグを導入していないでしょう。完了したら、システムをプロファイリングし、 'DefaultCellEditor'がホットスポットとして現れたら、それをカスタマイズしたり書き直したりしてください。問題空間を完全に理解し、実用的な解決策を得たら、最後に最適化してください。 – Faelkle
このクラスのコード（実際のバイトコード）は、インスタンス化するこのタイプのオブジェクトの数に関係なく、メモリのPermGen領域に1回だけロードされます。
AbstractCellEditorに機能を追加していないため、既にDefaultCellEditorにコードを再実装していますが、これは既にOracle（またはSun ）。
EJPによると、バグを導入するのは時間がかかり、潜在的ではありません。
メンバオブジェクトの数が少ないカスタムクラスを作成すると、メモリフットプリントが小さくなります。メソッドの数は、オブジェクトのサイズ、クラスの大きさには影響しません。
一般的には、実際に問題があると判断しない限り、私は時期尚早に最適化しません（つまり、オブジェクトの数千のインスタンスがあり、ヒープ/ガベージコレクタのログ分析によってメモリをスローしていることがわかります追加のコードが意味するので、）古い領域のコレクションが頻繁にあります。
CellEditorにバグではないことを保証する必要があるだろう）AFAIK、a CellEditorは、必要に応じてインスタンス化されるため、あまりメモリを節約できません。
"早すぎる最適化はすべての悪の根源です" –
@guido "早期最適化はすべての悪の根源です":) – Amarnath
マティアス、あなたはJVMがクラスのすべてのメソッドをロードしないと言っていますか？あなたはそれについての参考文献を持っていますか？ – Faelkle