- PR -

ユーティリティクラスをSingletonにしたときのデメリット

投稿者投稿内容
かつのり
ぬし
会議室デビュー日: 2004/03/18
投稿数: 2015
お住まい・勤務地: 札幌
投稿日時: 2005-06-30 19:42
インスタンスが必要ならシングルトンや通常のオブジェクトにすべきですし、
インスタンスが不要ならstaticメソッドで充分って感じがします。

インスタンスが必要なケースとは、状態を持つケースです。
例えば静的な設定ファイルを読み込む場合は、
staticメソッドなら何度も再読み込みが必要になりますが、
シングルトンなら1度で済みます。

適材適所で使用方法を選択すべきで、
ユーティリティならシングルトン云々・・・というのは関係ないと思います。
uk
ぬし
会議室デビュー日: 2003/05/20
投稿数: 1155
お住まい・勤務地: 東京都
投稿日時: 2005-07-01 13:48
引用:

かつのりさんの書き込み (2005-06-30 19:42) より:
インスタンスが必要なケースとは、状態を持つケースです。
例えば静的な設定ファイルを読み込む場合は、
staticメソッドなら何度も再読み込みが必要になりますが、
シングルトンなら1度で済みます。


いや、それならクラス変数に状態値を持って静的初期化子か、最初に呼び出されたタイミングで
ロードすれば同じことができますよ。

シングルトンでもstaticメソッドでもよい場合にシングルトンを選択する理由の一つは、利用
側のクラスの単体テストが書きやすいことです。
aa
ぬし
会議室デビュー日: 2004/01/08
投稿数: 299
投稿日時: 2005-07-01 20:23
引用:
シングルトンでもstaticメソッドでもよい場合にシングルトンを選択する理由の一つは、利用
側のクラスの単体テストが書きやすいことです。


利用側のクラスって、そのシングルトンを呼び出して使っているクラスの方ですか?
ぜんぜん関係ないと思いますが。というより、逆に単体テストしづらい気がしますけど。
ぽん
大ベテラン
会議室デビュー日: 2003/05/13
投稿数: 157
投稿日時: 2005-07-02 00:52
引用:

aaさんの書き込み (2005-07-01 20:23) より:
引用:
シングルトンでもstaticメソッドでもよい場合にシングルトンを選択する理由の一つは、利用
側のクラスの単体テストが書きやすいことです。


利用側のクラスって、そのシングルトンを呼び出して使っているクラスの方ですか?
ぜんぜん関係ないと思いますが。というより、逆に単体テストしづらい気がしますけど。



Singletonならテスト用のクラスに置き換える事も出来るので、テストしやすいですよ。
かつのり
ぬし
会議室デビュー日: 2004/03/18
投稿数: 2015
お住まい・勤務地: 札幌
投稿日時: 2005-07-02 10:31
引用:

ukさんの書き込み (2005-07-01 13:48) より:
いや、それならクラス変数に状態値を持って静的初期化子か、最初に呼び出されたタイミングで
ロードすれば同じことができますよ。


静的初期化子って例外の扱いが面倒じゃないですか?
全部例外キャッチして握りつぶすしかないですよね。
メソッドにすれば利用者側は例外の有無を検地できると思うのですが。

引用:

シングルトンでもstaticメソッドでもよい場合にシングルトンを選択する理由の一つは、利用
側のクラスの単体テストが書きやすいことです。


これは同意。静的ではないメソッドは抽象化が可能になりテストがしやすいですね。
aa
ぬし
会議室デビュー日: 2004/01/08
投稿数: 299
投稿日時: 2005-07-02 18:02
引用:
Singletonならテスト用のクラスに置き換える事も出来るので、テストしやすいですよ。


それはテストするためにソースを一時的に書き換えるって事ですよね。セッターで置き換えるとかではなくて。
koe
大ベテラン
会議室デビュー日: 2003/07/13
投稿数: 198
投稿日時: 2005-07-02 21:44
引用:

aaさんの書き込み (2005-07-02 18:02) より:
引用:
Singletonならテスト用のクラスに置き換える事も出来るので、テストしやすいですよ。


それはテストするためにソースを一時的に書き換えるって事ですよね。セッターで置き換えるとかではなくて。



そんな必要はありません。
コード:

public class Singleton{
protected static Singleton instance = new Singleton();
protected Singleton(){}
public static Singleton getInstance(){
// lazy initializationを行うコード。省略
return instance;
}
public String getConnection(){
Connection con = null;
//DB接続を取得するコード。省略
return con;
}
}

public class MockSingleton extends Singleton{
private static Singleton original;
public static void setUp(){
original = Singleton.instance
Singleton.instance = new MockSingleton();
}

public static void tearDown(){
Singleton.instance = original;
}

public String getConnection(){
Connection con = null;
//テスト用のMock接続を取得するコード。省略
return con;
}
}

public class UseConnectionTest extends TestCase{
protected void setUp(){
MockSingleton.setUp();
}
protected void tearDown(){
MockSingleton.tearDown();
}
public void testUseConnection() throws Exception{
//Singletonクラスを使う普段どおりのコード
}
}



Singleton側に拡張を許す仕掛けが必要ですが、それさえあれば任意のサブクラスに変更可能です。
上記のコードの善し悪しは、置いておいてください(;^ ^)。

追記です。
Singletonお決まりのgetInstance()が抜けてました。なんてこった・・・

[ メッセージ編集済み 編集者: koe 編集日時 2005-07-03 10:16 ]
uk
ぬし
会議室デビュー日: 2003/05/20
投稿数: 1155
お住まい・勤務地: 東京都
投稿日時: 2005-07-04 10:58
引用:

かつのりさんの書き込み (2005-07-02 10:31) より:
静的初期化子って例外の扱いが面倒じゃないですか?
全部例外キャッチして握りつぶすしかないですよね。
メソッドにすれば利用者側は例外の有無を検地できると思うのですが。


面倒です 基本的に例外が発生しないか、例外が発生しても構わないような処理にしか
使いません。

スキルアップ/キャリアアップ(JOB@IT)