0

HugeClasspublic メソッドaddButton() が定義されている場所で呼び出されるクラスがあります。

public class HugeClass{

public void addButton(){ etc... }
public HugeClass getHugeClass(){ etc... }

...lots of big number crunching logic...

}

myControllerを呼び出すというクラスがありますgetHugeClass()。

public class printController{
   ...
   myController.getHugeClass().addButton();    
}

私たちのクライアントは、コードが非常に長く、フロントエンドでフィールドを表示する際のロジックを処理するため、多くのメモリを消費するため、呼び出しを行わないことを望んでいます。より良い解決策はありますか？getHugeClass()printController

に拡張HugeClassしprintHugeClassてから呼び出すことを考えていprintControllerます。パフォーマンスは向上しますか、それとも元のクラスを途中で呼び出し、HugeClass親クラス全体も実行する必要があるため、パフォーマンスは同じになりますか?

4

4 に答える 4

2

どちらもaddButton適切に構築された のインスタンスを必要としHugeClass、それを回避する方法はありません (サブクラス化しても違いはありません)。

HugeClassまたは、呼び出しに含まれるすべての詳細は必要ないため、より小さな独立したコンポーネントにaddButton分割することを検討する時期かもしれません。HugeClass

参照。SRP (Single Responsibility Principle) に関するこの投稿。

于 2012-09-18T17:05:56.143 に答える
0

の残りの部分にどれだけaddButton()依存しHugeClassますか? クラスが非常に大きくなった場合は、クラスをリファクタリングして、必要な部分addButton()を別の新しいクラスに移動する価値があるかもしれません。

于 2012-09-18T17:06:49.280 に答える
0

まず第一に、Java のクラスの大きさは関係ありません。クラス ローダーは一度だけロードします。あなたのパフォーマンスの問題は何か他のものに関連しており、プロファイリング ツールを使用する必要があることがわかりました。

私のアドバイス：パフォーマンスの問題がある場合は、仮定をしないでください。それは何でもかまいません。静的初期化ブロックにロジックがない場合を除き、Java がクラスをロードする速度とは関係ありません。

于 2012-09-18T23:29:11.627 に答える
0

それはすべて、 の次のステートメントgetHugeClass()が必要であるという事実に依存しpritnControllerます。

..lots of big number crunching logic...

これらのステートメントを回避できる場合は、HugeClassオーバーライドするときに拡張すると問題が解決しますgetHugeClass()。

于 2012-09-18T17:06:01.367 に答える