Czy mogę dodać metody rozszerzeń do istniejącej klasy statycznej?

Jestem fanem metod rozszerzenia w języku C #, ale nie udało mi się dodać metody rozszerzenia do klasy statycznej, takiej jak konsola.

Na przykład, jeśli chcę dodać rozszerzenie do konsoli o nazwie „WriteBlueLine”, aby móc przejść:

Console.WriteBlueLine("This text is blue");

Próbowałem tego, dodając lokalną, publiczną metodę statyczną, z konsolą jako parametrem „to” ... ale żadnych kości!

public static class Helpers {
    public static void WriteBlueLine(this Console c, string text)
    {
        Console.ForegroundColor = ConsoleColor.Blue;
        Console.WriteLine(text);
        Console.ResetColor();
    }
}

Nie dodało to metody „WriteBlueLine” do konsoli ... czy robię to źle? Czy prosić o niemożliwe?

Nie. Metody rozszerzenia wymagają zmiennej obiektu (wartości) dla obiektu. Możesz jednak napisać statyczne opakowanie wokół ConfigurationManagerinterfejsu. Jeśli zaimplementujesz opakowanie, nie potrzebujesz metody rozszerzenia, ponieważ możesz po prostu dodać metodę bezpośrednio.

 public static class ConfigurationManagerWrapper
 {
      public static ConfigurationSection GetSection( string name )
      {
         return ConfigurationManager.GetSection( name );
      }

      .....

      public static ConfigurationSection GetWidgetSection()
      {
          return GetSection( "widgets" );
      }
 }

Czy możesz dodać statyczne rozszerzenia do klas w języku C #? Nie, ale możesz to zrobić:

public static class Extensions
{
    public static T Create<T>(this T @this)
        where T : class, new()
    {
        return Utility<T>.Create();
    }
}

public static class Utility<T>
    where T : class, new()
{
    static Utility()
    {
        Create = Expression.Lambda<Func<T>>(Expression.New(typeof(T).GetConstructor(Type.EmptyTypes))).Compile();
    }
    public static Func<T> Create { get; private set; }
}

Oto jak to działa. Chociaż technicznie nie można pisać statycznych metod rozszerzenia, ten kod wykorzystuje lukę w metodach rozszerzenia. Ta luka polega na tym, że możesz wywoływać metody rozszerzenia na obiektach zerowych bez uzyskania wyjątku zerowego (chyba że uzyskasz dostęp do czegokolwiek za pośrednictwem @ tego).

Oto, jak byś tego użył:

    var ds1 = (null as DataSet).Create(); // as oppose to DataSet.Create()
    // or
    DataSet ds2 = null;
    ds2 = ds2.Create();

    // using some of the techniques above you could have this:
    (null as Console).WriteBlueLine(...); // as oppose to Console.WriteBlueLine(...)

DLACZEGO dlaczego wybrałem jako przykład wywoływanie domyślnego konstruktora i ORAZ dlaczego po prostu nie zwracam nowej T () w pierwszym fragmencie kodu bez robienia wszystkich śmieci z wyrażeń? Cóż, dziś masz szczęśliwy dzień, bo dostajesz 2fer. Jak wie każdy zaawansowany programista .NET, nowa funkcja T () działa powoli, ponieważ generuje wywołanie do System.Activator, który używa odbicia, aby uzyskać domyślny konstruktor przed wywołaniem go. Cholera, Microsoft! Jednak mój kod wywołuje bezpośrednio domyślny konstruktor obiektu.

Rozszerzenia statyczne byłyby lepsze od tego, ale desperackie czasy wymagają desperackich środków.

To nie jest możliwe.

I tak, myślę, że stwardnienie rozsiane popełniło tutaj błąd.

Ich decyzja nie ma sensu i zmusza programistów do napisania (jak opisano powyżej) bezsensownej klasy opakowania.

Oto dobry przykład: Próba rozszerzenia statycznej klasy testowania MS Unit Assert: Chcę jeszcze 1 metodę Assert AreEqual(x1,x2).

Jedynym sposobem na to jest wskazanie różnych klas lub napisanie opakowania wokół setek różnych metod Assert. Dlaczego!?

Jeśli podjęto decyzję o zezwoleniu na rozszerzenia instancji, nie widzę logicznego powodu, aby nie zezwalać na rozszerzenia statyczne. Argumenty o bibliotekach sekcyjnych nie stoją po rozszerzeniu instancji.

Natknąłem się na ten wątek, próbując znaleźć odpowiedź na to samo pytanie, jakie miał OP. Nie znalazłem odpowiedzi, której chciałem, ale ostatecznie to zrobiłem.

public static class MyConsole
{
    public static void WriteLine(this ConsoleColor Color, string Text)
    {
        Console.ForegroundColor = Color;
        Console.WriteLine(Text);   
    }
}

I używam tego w ten sposób:

ConsoleColor.Cyan.WriteLine("voilà");

Być może możesz dodać klasę statyczną z niestandardową przestrzenią nazw i tą samą nazwą klasy:

using CLRConsole = System.Console;

namespace ExtensionMethodsDemo
{
    public static class Console
    {
        public static void WriteLine(string value)
        {
            CLRConsole.WriteLine(value);
        }

        public static void WriteBlueLine(string value)
        {
            System.ConsoleColor currentColor = CLRConsole.ForegroundColor;

            CLRConsole.ForegroundColor = System.ConsoleColor.Blue;
            CLRConsole.WriteLine(value);

            CLRConsole.ForegroundColor = currentColor;
        }

        public static System.ConsoleKeyInfo ReadKey(bool intercept)
        {
            return CLRConsole.ReadKey(intercept);
        }
    }
    class Program
    {
        static void Main(string[] args)
        {
            try
            {
                Console.WriteBlueLine("This text is blue");   
            }
            catch (System.Exception ex)
            {
                Console.WriteLine(ex.Message);
                Console.WriteLine(ex.StackTrace);
            }

            Console.WriteLine("Press any key to continue...");
            Console.ReadKey(true);
        }
    }
}

Począwszy od wersji C # 7 nie jest to obsługiwane. Trwają jednak dyskusje na temat włączenia czegoś takiego w C # 8 i propozycji wartych poparcia .

Nie. Definicje metod rozszerzenia wymagają wystąpienia rozszerzanego typu. To niefortunne; Nie jestem pewien, dlaczego jest to wymagane ...

Jeśli chodzi o metody rozszerzenia, same metody rozszerzenia są statyczne; ale są wywoływane tak, jakby były metodami instancji. Ponieważ klasa statyczna nie jest możliwa do utworzenia, nigdy nie będzie instancji klasy, z której można by wywołać metodę rozszerzenia. Z tego powodu kompilator nie zezwala na definiowanie metod rozszerzeń dla klas statycznych.

Pan Obnoxious napisał: „Jak wie każdy zaawansowany programista .NET, nowa T () działa wolno, ponieważ generuje wywołanie do System.Activator, który używa odbicia, aby uzyskać domyślny konstruktor przed wywołaniem go”.

New () jest kompilowany do instrukcji IL „newobj”, jeśli typ jest znany w czasie kompilacji. Newobj pobiera konstruktora do bezpośredniego wywoływania. Wywołania System.Activator.CreateInstance () kompilują się z instrukcją IL „call” w celu wywołania System.Activator.CreateInstance (). Funkcja New () zastosowana wobec typów ogólnych spowoduje wywołanie funkcji System.Activator.CreateInstance (). Wpis pana Obnoxiousa był niejasny w tej kwestii ... i cóż, wstrętny.

Ten kod:

System.Collections.ArrayList _al = new System.Collections.ArrayList();
System.Collections.ArrayList _al2 = (System.Collections.ArrayList)System.Activator.CreateInstance(typeof(System.Collections.ArrayList));

produkuje tę IL:

  .locals init ([0] class [mscorlib]System.Collections.ArrayList _al,
           [1] class [mscorlib]System.Collections.ArrayList _al2)
  IL_0001:  newobj     instance void [mscorlib]System.Collections.ArrayList::.ctor()
  IL_0006:  stloc.0
  IL_0007:  ldtoken    [mscorlib]System.Collections.ArrayList
  IL_000c:  call       class [mscorlib]System.Type [mscorlib]System.Type::GetTypeFromHandle(valuetype [mscorlib]System.RuntimeTypeHandle)
  IL_0011:  call       object [mscorlib]System.Activator::CreateInstance(class [mscorlib]System.Type)
  IL_0016:  castclass  [mscorlib]System.Collections.ArrayList
  IL_001b:  stloc.1

Nie możesz dodać statycznego metod do typu. Można dodawać tylko metody (pseudo) instancji do instancji typu.

Celem thismodyfikatora jest poinformowanie kompilatora C #, aby przekazał instancję po lewej stronie .jako pierwszy parametr metody static / extension.

W przypadku dodawania metod statycznych do typu nie ma instancji do przekazania dla pierwszego parametru.

Próbowałem to zrobić za pomocą System.Environment, kiedy uczyłem się metod rozszerzania i nie powiodło się. Powodem jest, jak wspominają inni, ponieważ metody rozszerzenia wymagają wystąpienia klasy.

Nie można napisać metody rozszerzenia, jednak można naśladować zachowanie, o które prosisz.

using FooConsole = System.Console;

public static class Console
{
    public static void WriteBlueLine(string text)
    {
        FooConsole.ForegroundColor = ConsoleColor.Blue;
        FooConsole.WriteLine(text);
        FooConsole.ResetColor();
    }
}

Umożliwi to wywołanie Console.WriteBlueLine (fooText) w innych klasach. Jeśli inne klasy chcą uzyskać dostęp do innych statycznych funkcji konsoli, będą musiały zostać jawnie przywołane poprzez ich przestrzeń nazw.

Zawsze możesz dodać wszystkie metody do klasy zastępczej, jeśli chcesz mieć je wszystkie w jednym miejscu.

Więc miałbyś coś takiego

using FooConsole = System.Console;

public static class Console
{
    public static void WriteBlueLine(string text)
    {
        FooConsole.ForegroundColor = ConsoleColor.Blue;
        FooConsole.WriteLine(text);
        FooConsole.ResetColor();
    }
    public static void WriteLine(string text)
    {
        FooConsole.WriteLine(text);
    }
...etc.
}

Zapewniłoby to rodzaj zachowania, którego szukasz.

* Uwaga: Konsola będzie musiała zostać dodana poprzez przestrzeń nazw, w której została umieszczona.

tak, w ograniczonym sensie.

public class DataSet : System.Data.DataSet
{
    public static void SpecialMethod() { }
}

To działa, ale konsola nie działa, ponieważ jest statyczna.

public static class Console
{       
    public static void WriteLine(String x)
    { System.Console.WriteLine(x); }

    public static void WriteBlueLine(String x)
    {
        System.Console.ForegroundColor = ConsoleColor.Blue;
        System.Console.Write(.x);           
    }
}

Działa to, o ile nie znajduje się w tej samej przestrzeni nazw. Problem polega na tym, że musisz napisać statyczną metodę proxy dla każdej metody, jaką posiada System.Console. To niekoniecznie zła rzecz, ponieważ możesz dodać coś takiego:

    public static void WriteLine(String x)
    { System.Console.WriteLine(x.Replace("Fck","****")); }

lub

 public static void WriteLine(String x)
    {
        System.Console.ForegroundColor = ConsoleColor.Blue;
        System.Console.WriteLine(x); 
    }

Działa to tak, że podpinasz coś do standardowej linii WriteLine. Może to być liczba wierszy, filtr niepoprawnych słów lub cokolwiek innego. Ilekroć po prostu określisz konsolę w przestrzeni nazw, powiedz WebProject1 i zaimportuj przestrzeń nazw System, WebProject1.Console zostanie wybrana zamiast System.Console jako domyślna dla tych klas w przestrzeni nazw WebProject1. Tak więc ten kod zmieni wszystkie wywołania Console.WriteLine w niebieskie, o ile nigdy nie podano System.Console.WriteLine.

Poniższe zostało odrzucone jako edycja odpowiedzi tvanfosson. Poproszono mnie o udzielenie odpowiedzi jako mojej własnej odpowiedzi. Skorzystałem z jego sugestii i zakończyłem implementację ConfigurationManageropakowania. Zasadniczo po prostu wypełniłem odpowiedź ...w tvanfosson.

Nie. Metody rozszerzania wymagają wystąpienia obiektu. Możesz jednak napisać statyczne opakowanie wokół interfejsu ConfigurationManager. Jeśli zaimplementujesz opakowanie, nie potrzebujesz metody rozszerzenia, ponieważ możesz po prostu dodać metodę bezpośrednio.

public static class ConfigurationManagerWrapper
{
    public static NameValueCollection AppSettings
    {
        get { return ConfigurationManager.AppSettings; }
    }

    public static ConnectionStringSettingsCollection ConnectionStrings
    {
        get { return ConfigurationManager.ConnectionStrings; }
    }

    public static object GetSection(string sectionName)
    {
        return ConfigurationManager.GetSection(sectionName);
    }

    public static Configuration OpenExeConfiguration(string exePath)
    {
        return ConfigurationManager.OpenExeConfiguration(exePath);
    }

    public static Configuration OpenMachineConfiguration()
    {
        return ConfigurationManager.OpenMachineConfiguration();
    }

    public static Configuration OpenMappedExeConfiguration(ExeConfigurationFileMap fileMap, ConfigurationUserLevel userLevel)
    {
        return ConfigurationManager.OpenMappedExeConfiguration(fileMap, userLevel);
    }

    public static Configuration OpenMappedMachineConfiguration(ConfigurationFileMap fileMap)
    {
        return ConfigurationManager.OpenMappedMachineConfiguration(fileMap);
    }

    public static void RefreshSection(string sectionName)
    {
        ConfigurationManager.RefreshSection(sectionName);
    }
}

Możesz użyć rzutowania na wartość NULL, aby działało.

public static class YoutTypeExtensionExample
{
    public static void Example()
    {
        ((YourType)null).ExtensionMethod();
    }
}

Rozszerzenie:

public static class YourTypeExtension
{
    public static void ExtensionMethod(this YourType x) { }
}

Twój typ:

public class YourType { }

Możesz to zrobić, jeśli zechcesz trochę „fregować”, tworząc zmienną klasy statycznej i przypisując jej wartość null. Jednak ta metoda nie byłaby dostępna dla wywołań statycznych w klasie, więc nie jestem pewien, ile by to wykorzystało:

Console myConsole = null;
myConsole.WriteBlueLine("my blue line");

public static class Helpers {
    public static void WriteBlueLine(this Console c, string text)
    {
        Console.ForegroundColor = ConsoleColor.Blue;
        Console.WriteLine(text);
        Console.ResetColor();
    }
}