C#ではこのような書き方は避けるべきなのか
- 評価
- クリップ 0
- VIEW 2,138
C#初心者です。
複数のクラスのインスタンスを生成する方法について考えていました。
最初に考えたコードをコード1に示します。
Class1, Class2, ... のように連続する名前のクラスを作りました。
そしてこれらのインスタンスを生成するコードも書きました。
Program::createInstanceがそれです。
// コード1
using System;
class Program
{
public static void Main()
{
Console.WriteLine(createInstance(1).Name);
Console.WriteLine(createInstance(2).Name);
}
// インスタンスを生成する (例外に対する処理は今回は省いてあります)
public static ClassBase createInstance(int num)
=> Activator.CreateInstance(Type.GetType($"Class{num}")) as ClassBase;
}
abstract class ClassBase
{
public abstract string Name { get; }
}
class Class1 : ClassBase
{
public override string Name
=> "クラス1";
}
class Class2 : ClassBase
{
public override string Name
=> "クラス2";
}
例外処理などは省きましたが、このような感じです。
さて、このように書いてしまいましたが、
静的な型指定をした場合に比べて
危険なコードになったと思います。
なので、静的な型指定をする方法に変えてみました。
それをコード2に示します。
// コード2
using System;
class Program
{
public static void Main()
{
Console.WriteLine(createInstance(1).Name);
Console.WriteLine(createInstance(2).Name);
}
public static ClassBase createInstance(int num)
{
switch (num)
{
case 1:
return new Class1();
case 2:
return new Class2();
default:
return null;
}
}
}
abstract class ClassBase
{
public abstract string Name { get; }
}
class Class1 : ClassBase
{
public override string Name
=> "クラス1";
}
class Class2 : ClassrBase
{
public override string Name
=> "クラス2";
}
確かにコード2はコード1に比べて安全になったのかもしれませんが、
コードを書く量が増えました。
コード1中のProgram::createInstanceは
ClassBaseの派生クラスの数がどれだけ増えても1行、
例外を対処するコードを入れたとしても
それほど量は増えないでしょう。
それに対して、コード2中のProgram::createInstanceは
ClassBaseの派生クラスの数が増えれば増えるほど
コードが長くなります。
たとえば Class1 から Class718 までクラスがあるとすると
コード2の書き方でいけば
Program::createInstanceは2159行にもなることが予想されます。
いくら安全性のためとはいえ
これは大変だと思います。
そこで疑問に思いました。
皆さんなら
・コード1のやり方
・コード2のやり方
・それ以外のやり方
どのように書きますか。
追記
例を変えました。
あと、「必ずしもクラスにする必要は無いのではないか?」
という回答もやめてください。
-
気になる質問をクリップする
クリップした質問は、後からいつでもマイページで確認できます。
またクリップした質問に回答があった際、通知やメールを受け取ることができます。
クリップを取り消します
-
良い質問の評価を上げる
以下のような質問は評価を上げましょう
- 質問内容が明確
- 自分も答えを知りたい
- 質問者以外のユーザにも役立つ
評価が高い質問は、TOPページの「注目」タブのフィードに表示されやすくなります。
質問の評価を上げたことを取り消します
-
評価を下げられる数の上限に達しました
評価を下げることができません
- 1日5回まで評価を下げられます
- 1日に1ユーザに対して2回まで評価を下げられます
質問の評価を下げる
teratailでは下記のような質問を「具体的に困っていることがない質問」、「サイトポリシーに違反する質問」と定義し、推奨していません。
- プログラミングに関係のない質問
- やってほしいことだけを記載した丸投げの質問
- 問題・課題が含まれていない質問
- 意図的に内容が抹消された質問
- 過去に投稿した質問と同じ内容の質問
- 広告と受け取られるような投稿
評価が下がると、TOPページの「アクティブ」「注目」タブのフィードに表示されにくくなります。
質問の評価を下げたことを取り消します
この機能は開放されていません
評価を下げる条件を満たしてません
質問の評価を下げる機能の利用条件
この機能を利用するためには、以下の事項を行う必要があります。
- 質問回答など一定の行動
-
メールアドレスの認証
メールアドレスの認証
-
質問評価に関するヘルプページの閲覧
質問評価に関するヘルプページの閲覧
checkベストアンサー
+1
こんにちは。
確かにコード2はコード1に比べて安全になったのかもしれませんが、
monsterIdに不正な値が渡された時どちらもエラー処理が必要です。そして、このケースならば前者もtry-catchすれば、安全性は大差ないような気がします。
C#処理系のバグまで視野に入れるとなんとなくリフレクションの信頼性は低いような気はしますが、それは気のせいかも。
ただ、それを除いてもリフレクションは遅いことと、使い方が妙に難しいのであまり積極的には使いたくないです。なので、派生クラスの数が精々一桁であれば私は後者を選ぶと思います。二桁越えるなら前者を選ぶかも。
投稿
-
回答の評価を上げる
以下のような回答は評価を上げましょう
- 正しい回答
- わかりやすい回答
- ためになる回答
評価が高い回答ほどページの上位に表示されます。
-
回答の評価を下げる
下記のような回答は推奨されていません。
- 間違っている回答
- 質問の回答になっていない投稿
- スパムや攻撃的な表現を用いた投稿
評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。
+1
派生クラスが700以上もあるとなると、やはりコード1方式がベースになるかと。
ただし、実在するクラス名であることをテストする Assert() を入れるか、せめて try catch で例外をハンドリングするくらいのことは必要ではないかと思います。
投稿
-
回答の評価を上げる
以下のような回答は評価を上げましょう
- 正しい回答
- わかりやすい回答
- ためになる回答
評価が高い回答ほどページの上位に表示されます。
-
回答の評価を下げる
下記のような回答は推奨されていません。
- 間違っている回答
- 質問の回答になっていない投稿
- スパムや攻撃的な表現を用いた投稿
評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。
15分調べてもわからないことは、teratailで質問しよう!
- ただいまの回答率 88.37%
- 質問をまとめることで、思考を整理して素早く解決
- テンプレート機能で、簡単に質問をまとめられる
2016/05/21 23:45
自分の中ではリフレクションは
なんか怖いイメージが合ったので
使っていいのかどうか迷っていました。
やはり、数が多い場合は
使うのも手ですよね。