を使用するスイングベースのアプリケーションを実行していますJTable。DefaultCellEditorコンボボックスの選択が必要な列の1つに使用しました。しかし、DefaultCellEditor私が必要としない多くのメソッドがあります。AbstractCellEditorそこで、必要なメソッドのみを実装した場所を拡張してカスタム CellEditor を作成しました。私の質問は
（一般に）クラスがあり、そのクラスのすべてのメソッドを必要としない場合、それを使用しても問題ありませんか、それとも必要なメソッドのみを実装するカスタムクラスを作成するのが良いですか? と
カスタム クラスを使用すると、アプリケーションのパフォーマンス (メモリに関して) が向上しますか、それともすべてのメソッドを持つクラスと同じままですか?
どんな助けでも大歓迎です。
JDK 自体を含むアプリケーションで他に何も使用していないと信じるに足る十分な根拠がない限り、DefaultCellEditor,状況を積極的に悪化させて時間を無駄にしていることはほぼ確実です。
また、典型的な JVMS が実行に約 1 ギガバイトを使用する極端なケースでは、おそらく 100k のコードを節約できた可能性があることも考慮する必要があります。したがって、コード スペースの 0.01% を節約できた可能性があります。これは時間の生産的な使い方ではありません。正しい手順は、時間とスペースのボトルネックが実際にどこにあるのかを事後にテストして測定することです。プログラマーは、これらのことを予測するのが苦手なことで有名です。
このクラスのコード (実際のバイトコード) は、インスタンス化するこのタイプのオブジェクトの数に関係なく、メモリの PermGen 領域に 1 回だけ読み込まれます。
すでに利用可能な機能を複製していて、に機能を追加していないため、このコードは受け入れません.Oracle（またはSun）によって（うまくいけば）すでにテストされているAbstractCellEditorコードを再実装しています。DefaultCellEditor
EJP が言ったように、バグを導入する時間と潜在的な価値はありません。
メンバー オブジェクトの数が少ないカスタム クラスを作成すると、メモリ フットプリントが少なくなります。メソッドの数はオブジェクトのサイズには影響せず、クラスのサイズだけに影響します。
一般に、実際に問題があると判断しない限り、時期尚早に最適化することはありません (つまり、オブジェクトのインスタンスが何千もあり、ヒープ/ガベージ コレクターのログ分析により、メモリをスラッシングしている、および/またはコレクションが頻繁に発生していることが明らかになった場合)。これは、追加のコードが次のことを意味するためです。
CellEditor追加のメンテナンス (カスタムにバグがないことを確認する必要があります)私の知る限り、 aCellEditorは必要に応じてインスタンス化されるため、とにかく多くのメモリを節約できません。