Чи можна додати методи розширення до існуючого статичного класу?

Я прихильник методів розширення в C #, але не мав жодного успіху, додавши метод розширення до статичного класу, наприклад консолі.

Наприклад, якщо я хочу додати розширення до консолі під назвою "WriteBlueLine", щоб я міг перейти:

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

Я спробував це, додавши локальний, загальнодоступний статичний метод із консоллю як "цей" параметр ... але без кісток!

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

Це не додало метод "WriteBlueLine" до консолі ... чи я це роблю неправильно? Або просити неможливе?

Ні. Методи розширення вимагають змінної екземпляра (значення) для об'єкта. Однак ви можете написати статичну обгортку навколо ConfigurationManagerінтерфейсу. Якщо ви реалізуєте обгортку, вам не потрібен метод розширення, оскільки ви можете просто додати метод безпосередньо.

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

      .....

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

Чи можете ви додати статичні розширення до класів у C #? Ні, але ви можете це зробити:

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; }
}

Ось як це працює. Хоча технічно не можна писати статичні методи розширення, натомість цей код використовує лазівку в методах розширення. Ця лазівка ​​полягає в тому, що ви можете викликати методи розширення на нульових об'єктах, не отримуючи нульового винятку (якщо ви нічого не отримуєте через @this).

Отже, ось як би ви цим скористалися:

    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(...)

Тепер ЧОМУ я вибрав за приклад конструктор за замовчуванням, і чому я просто не повертаю новий T () у перший фрагмент коду, не виконуючи все це сміття Expression? Ну сьогодні ваш щасливий день, тому що ви отримуєте 2fer. Як знає будь-який просунутий розробник .NET, новий T () повільний, оскільки він генерує виклик до System.Activator, який використовує відображення, щоб отримати конструктор за замовчуванням, перш ніж викликати його. Чорт за тобою, Microsoft! Однак мій код безпосередньо викликає конструктор за замовчуванням об'єкта.

Статичне розширення було б краще, ніж це, але відчайдушні часи вимагають відчайдушних заходів.

Це неможливо.

І так, я думаю, що MS тут помилилася.

Їх рішення не має сенсу і змушує програмістів написати (як описано вище) безглуздий клас обгортки.

Ось хороший приклад: Спроба розширити статичний клас тестування MS Unit Assert: Я хочу ще 1 метод Assert AreEqual(x1,x2) .

Єдиний спосіб зробити це - вказати на різні класи або написати обгортку приблизно 100-х різних методів Assert. Чому !?

Якщо було прийнято рішення дозволити розширення примірників, я не бачу логічної причини не дозволяти статичних розширень. Аргументи щодо розділення бібліотек не стоять, коли екземпляри можуть бути розширені.

Я натрапив на цю нитку, намагаючись знайти відповідь на те саме питання, що було і в ОП. Я не знайшов відповіді, яку хотів, але закінчив це робити.

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

І я використовую це так:

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

Можливо, ви можете додати статичний клас зі своїм власним простором імен та тим самим іменем класу:

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);
        }
    }
}

Станом на C # 7 це не підтримується. Однак є дискусії щодо інтеграції чогось подібного в C # 8 та пропозиції, які варто підтримати .

Ні. Визначення методу розширення вимагає екземпляра типу, який ви розширюєте. Це прикро; Я не впевнений, чому це потрібно ...

Що стосується методів розширення, то самі методи розширення є статичними; але вони викликаються так, ніби вони є методами екземпляра. Оскільки статичний клас не є миттєвим, у вас ніколи не буде екземпляра класу, з якого слід викликати метод розширення. З цієї причини компілятор не дозволяє визначати методи розширення для статичних класів.

Пан Obnoxious писав: "Як знає будь-який просунутий розробник .NET, новий T () повільний, оскільки він генерує виклик до System.Activator, який використовує відображення для отримання конструктора за замовчуванням, перш ніж викликати його".

New () компілюється в інструкцію IL "newobj", якщо тип відомий під час компіляції. Newobj приймає конструктор для прямого виклику. Виклики до System.Activator.CreateInstance () компілюють в інструкцію IL "call" для виклику System.Activator.CreateInstance (). Новий () при використанні проти загальних типів призведе до виклику System.Activator.CreateInstance (). Пост містера Обидних з цього приводу був незрозумілим ... і ну, неприємним.

Цей код:

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

виробляє цю ІЛ:

  .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

Ви не можете додати статичні методи до типу. Ви можете додавати (псевдо-) екземплярні методи до примірника типу.

Сенс thisмодифікатора полягає в тому, щоб сказати компілятору C # передати екземпляр ліворуч від. як перший параметр методу статичного / розширення.

У разі додавання статичних методів до типу, для першого параметра немає жодного примірника.

Я намагався це зробити з System.Environment ще тоді, коли вивчав методи розширення і не мав успіху. Причина, як зазначають інші, тому, що методи розширення вимагають екземпляра класу.

Неможливо написати метод розширення, проте можна імітувати поведінку, про яку ви просите.

using FooConsole = System.Console;

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

Це дозволить вам викликати Console.WriteBlueLine (fooText) в інших класах. Якщо інші класи хочуть отримати доступ до інших статичних функцій консолі, на них доведеться чітко посилатися через простір імен.

Ви завжди можете додати всі методи до класу заміни, якщо хочете мати їх у одному місці.

Тож у вас вийшло щось подібне

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.
}

Це забезпечить поведінку, яку ви шукаєте.

* Примітка консолі потрібно буде додати через простір імен, в який ви вводите її.

так, у обмеженому розумінні.

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

Це працює, але консоль не робить, тому що вона статична.

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);           
    }
}

Це працює тому, що поки він не знаходиться в одному просторі імен. Проблема полягає в тому, що ви повинні написати статичний метод проксі для кожного методу, який має System.Console. Це не обов'язково погано, оскільки ви можете додати щось подібне:

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

або

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

Як це працює, це те, що ви підключите щось до стандартного WriteLine. Це може бути кількість рядків або фільтр поганих слів чи будь-що інше. Кожен раз, коли ви просто вкажете консоль у вашому просторі імен, скажімо, WebProject1 та імпортуйте систему простору імен, WebProject1.Console буде обраний через System.Console як стандартний для цих класів у просторі імен WebProject1. Таким чином, цей код перетворить усі виклики Console.WriteLine в синій, наскільки ви ніколи не вказували System.Console.WriteLine.

Далі було відхилено як редагування відповіді tvanfosson. Мене попросили внести це як власну відповідь. Я використав його пропозицію і закінчив реалізацію ConfigurationManagerобгортки. У принципі я просто заповнив відповідь ...в tvanfosson.

Ні. Методи розширення вимагають примірника об'єкта. Однак ви можете написати статичну обгортку навколо інтерфейсу ConfigurationManager. Якщо ви реалізуєте обгортку, вам не потрібен метод розширення, оскільки ви можете просто додати метод безпосередньо.

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);
    }
}

Ви можете використовувати ролик на null, щоб він працював.

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

Розширення:

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

Ваш тип:

public class YourType { }

Ви МОЖЕТЕ це зробити, якщо ви хочете трохи «фрігнути» його, зробивши змінну статичного класу та призначивши її нульовою. Однак цей метод не буде доступний для статичних дзвінків у класі, тому не впевнений, якою користю він користуватиметься:

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();
    }
}