クラスを使用するすべてのファイルにコード行を追加せずに、C＃でクラス名のエイリアスを作成するにはどうすればよいですか？

Question 1

クラス名のエイリアスを作成したい。次の構文は完璧です。

public class LongClassNameOrOneThatContainsVersionsOrDomainSpecificName
{
   ...
}

public class MyName = LongClassNameOrOneThatContainsVersionOrDomainSpecificName;

しかし、それはコンパイルされません。

例

注この例は、便宜上提供されています。システム全体の設計を変更することを提案して、この特定の問題を解決しようとしないでください。この例の存在または欠如は、元の質問を変更しません。

一部の既存のコードは、静的クラスの存在に依存しています。

public static class ColorScheme
{
   ...
}

この配色は、Outlook2003の配色です。Outlook 2003の配色を維持しながら、Outlook2007の配色を導入したいと思います。

public static class Outlook2003ColorScheme
{
   ...
}

public static class Outlook2007ColorScheme
{
   ...
}

しかし、私はまだコードがと呼ばれる静的クラスの存在に依存しているという事実に直面していColorSchemeます。私の最初の考えは、次のColorSchemeいずれOutlook2003かから継承するクラスを作成することでしたOutlook2007。

public static class ColorScheme : Outlook2007ColorScheme
{
}

ただし、静的クラスから継承することはできません。

私の次の考えは静的ColorSchemeクラスを作成することでしたが、makeOutlook2003ColorSchemeとOutlook2007ColorSchemeclassesは非静的です。次に、静的ColorSchemeクラスの静的変数は、次のいずれかの「真の」配色を指すことができます。

public static class ColorScheme
{
    private static CustomColorScheme = new Outlook2007ColorScheme();
    ...
}

private class CustomColorScheme 
{ 
   ...
}

private class Outlook2008ColorScheme : CustomColorScheme 
{
    ...
}

private class Outlook2003ColorScheme : CustomColorScheme 
{
   ...
}

ただし、読み取り専用の静的Colorで構成されたクラスをオーバーライド可能なプロパティに変換する必要があります。次に、ColorSchemeクラスで30個の異なるプロパティゲッターを含まれているオブジェクトにサンクダウンする必要があります。

タイピングが多すぎます。

したがって、次の考えは、クラスのエイリアスを作成することでした。

public static ColorScheme = Outlook2007ColorScheme;

しかし、それはコンパイルされません。

静的クラスを別の名前にエイリアスするにはどうすればよいですか？

更新：誰かが「C＃ではこれを行うことはできません」という回答を追加してください。それを承認済みの回答としてマークできます。同じ質問への回答が必要な他の人は、この質問、受け入れられた回答、および役立つ場合とそうでない場合があるいくつかの回避策を見つけるでしょう。

この質問を締めくくりたいと思います。

Question 2

できません。次善の策は、クラスを使用するファイルに宣言を含めることですusing。

たとえば、インポートエイリアスを使用して（準typedef代替として）依存コードを書き直すことができます。

using ColorScheme = The.Fully.Qualified.Namespace.Outlook2007ColorScheme;

残念ながら、これは名前を使用するすべてのスコープ/ファイルに入る必要があります。

したがって、これがあなたの場合に実用的かどうかはわかりません。

Question 3

次のコード行を追加することで、クラスのエイリアスを作成できます。

using Outlook2007ColorScheme = YourNameSpace.ColorScheme;

Question 4

あなたは（要件に応じてファクトリ|シングルトン）が必要です。前提は、クライアントコードが取得している配色を知る必要がないようにすることです。配色をアプリケーション全体に適用する必要がある場合は、シングルトンで十分です。さまざまな状況でさまざまなスキームを使用する可能性がある場合は、ファクトリパターンがおそらく最適な方法です。いずれにせよ、配色を変更する必要がある場合は、コードを1か所で変更するだけで済みます。

public interface ColorScheme {
    Color TitleBar { get; }
    Color Background{ get; }
    ...
}

public static class ColorSchemeFactory {

    private static ColorScheme scheme = new Outlook2007ColorScheme();

    public static ColorScheme GetColorScheme() { //Add applicable arguments
        return scheme;
    }
}

public class Outlook2003ColorScheme: ColorScheme {
   public Color TitleBar {
       get { return Color.LightBlue; }
   }

    public Color Background {
        get { return Color.Gray; }
    }
}

public class Outlook2007ColorScheme: ColorScheme {
   public Color TitleBar {
       get { return Color.Blue; }
   }

    public Color Background {
        get { return Color.White; }
    }
}

Question 5

C＃でクラス名をエイリアスすることはできません。

C＃でクラス名をエイリアスしないでできることがあります。

ただし、元の質問に答えるには、C＃でクラス名をエイリアスすることはできません。

更新：人々はなぜusing機能しないのか混乱しています。例：

Form1.cs

private void button1_Click(object sender, EventArgs e)
{
   this.BackColor = ColorScheme.ApplyColorScheme(this.BackColor);
}

ColorScheme.cs

class ColorScheme
{
    public static Color ApplyColorScheme(Color c) { ... }
}

そして、すべてが機能します。今、私は新しいクラスを作成し、そのエイリアス を作成したいと思いますColorScheme（コードを変更する必要がないように）：

ColorScheme.cs

using ColorScheme = Outlook2007ColorScheme;

class Outlook2007ColorScheme
{
    public static Color ApplyColorScheme(Color c) { ... }
}

ああ、ごめんなさい。このコードはコンパイルされません：

ここに画像の説明を入力してください

私の質問は、C＃でクラスをエイリアスする方法でした。それはできません。C＃でクラス名をエイリアスしないでできることがあります。

依存して変化するみんなColorSchemeのusing ColorScheme代わりに（私は別名ができないため、コードの変更は回避）
ColorSchemeファクトリパターンを使用することに依存しているすべての人をポリモーフィッククラスまたはインターフェイスに変更します（エイリアスできないため、コード変更の回避策）

ただし、これらの回避策には、既存のコードの破壊が含まれます。オプションではありません。

人々がColorSchemeクラスの存在に依存している場合、私は実際にColorSchemeクラスをコピーして貼り付ける必要があります。

言い換えると、C＃でクラス名をエイリアスすることはできません。

これは、エイリアスを定義できる他のオブジェクト指向言語とは対照的です。

ColorScheme = Outlook2007ColorScheme

そして、私は終わります。

Question 6

これを試して：

using ColorScheme=[fully qualified].Outlook2007ColorScheme

Question 7

OPが「回答」を受け入れてからずっと後にこれを見つけたユーザーのために、このコメントを追加します。C＃でのエイリアスは、完全修飾名前空間を使用してクラス名を指定することで機能します。定義されたエイリアス名は、そのスコープ内で使用できます。例。

using aliasClass = Fully.Qualified.Namespace.Example;
//Example being the class in the Fully.Qualified.Namespace

public class Test{

  public void Test_Function(){

    aliasClass.DoStuff();
    //aliasClass here representing the Example class thus aliasing
    //aliasClass will be in scope for all code in my Test.cs file
  }

}

すばやく入力されたコードについてお詫びしますが、C＃では実行できないとユーザーが誤解しないように、これを実装する方法を説明していることを願っています。

Question 8

希望する方法でエイリアスを作成しても、C＃では機能しません。これは、エイリアシングがusingディレクティブを介して行われるためです。ディレクティブは、問題のファイル/名前空間に限定されています。古いクラス名を使用するファイルが50個ある場合、更新する場所は50個になります。

そうは言っても、コードの変更を可能な限り最小限に抑える簡単な解決策があると思います。を作るColorSchemeたクラスに実装して、実際のクラスへのあなたの通話用ファサードを、そして使用usingするかを決定するために、そのファイルにColorScheme使用します。

言い換えれば、これを行います：

using CurrentColorScheme = Outlook2007ColorScheme;
public static class ColorScheme
{
   public static Color ApplyColorScheme(Color c)
   {
       return CurrentColorScheme.ApplyColorScheme(c);
   }
   public static Something DoSomethingElse(Param a, Param b)
   {
       return CurrentColorScheme.DoSomethingElse(a, b);
   }
}

次に、コードビハインドで何も変更しません。

private void button1_Click(object sender, EventArgs e)
{
   this.BackColor = ColorScheme.ApplyColorScheme(this.BackColor);
}

その後、の値を更新できます ColorScheme 1行のコード（using CurrentColorScheme = Outlook2008ColorScheme;）を。

ここでいくつかの懸念があります：

次に、すべての新しいメソッドまたはプロパティ定義を、ColorSchemeクラスとクラスの2か所に追加する必要があります。Outlook2007ColorScheme。これは余分な作業ですが、これが真のレガシーコードである場合は、頻繁に発生することはありません。ボーナスとして、のコードColorSchemeは非常に単純なので、起こりうるバグは非常に明白です。
この静的クラスの使用は、私には自然に思えません。私はおそらくこれを別の方法で行うためにレガシーコードをリファクタリングしようとしますが、あなたの状況ではそれが許されないかもしれないことも理解しています。
ColorScheme置き換えるクラスがすでにある場合は、このアプローチやその他のアプローチが問題になる可能性があります。そのクラスの名前をのような名前に変更してからColorSchemeOld、を介してアクセスすることをお勧めしますusing CurrentColorScheme = ColorSchemeOld;。

Question 9

何も追加しなくても、いつでも基本クラスから継承できると思います

public class Child : MyReallyReallyLongNamedClass {}

更新

ただし、classそれ自体をリファクタリングする機能がある場合：namespacesがないため、クラス名は通常、不必要に長くなります。

あなたのように例が表示された場合はApiLoginUser、DataBaseUser、WebPortalLoginUser、通常の欠如の指標であるnamespace名前の恐怖によるUserかもしれないが競合。

ただし、この場合、上記の投稿で指摘されているように、namespaceエイリアスを使用できます。

using LoginApi = MyCompany.Api.Login;
using AuthDB = MyCompany.DataBase.Auth;
using ViewModels = MyCompany.BananasPortal.Models;

// ...
AuthDB.User dbUser;
using ( var ctxt = new AuthDB.AuthContext() )
{
    dbUser = ctxt.Users.Find(userId);
}

var apiUser = new LoginApi.Models.User {
        Username = dbUser.EmailAddess,
        Password = "*****"
    };

LoginApi.UserSession apiUserSession = await LoginApi.Login(apiUser);
var vm = new ViewModels.User(apiUserSession.User.Details);
return View(vm);

class名前はすべてUserですが、namespacesが異なることに注意してください。PEP-20の引用：Pythonの禅：

名前空間は素晴らしいアイデアの1つです。もっと多くのことをしましょう！

お役に立てれば

Question 10

インターフェイスの使用に変更することはできますか？

おそらくIColorScheme、すべてのクラスが実装するインターフェースを作成できますか？

これは、ChrisMarasti-Georgによって示されているファクトリパターンでうまく機能します。

Question 11

これは非常に遅い部分的な答えですが、同じクラス「ColorScheme」を同じ名前空間「Outlook」で定義し、一方がOutlook2003ともう一方のOutlook2007と呼ばれる別々のアセンブリで定義する場合、必要なのは適切なアセンブリを参照することだけです。。