Алексей Немиро

Интерфейсы использую, если это необходимо :-) Как я понимаю, что это необходимо, сказать сложно. Все зависит от задачи. Если рассматривать вопрос с позиции создания интерфейсов, то иногда это может быть очевидно, а иногда приходится подумать, стоит использовать интерфейсы или нет. Пихать их где попало - плохая идея.

Готовые интерфейсы, да, часто используются. Самым популярным в .NET наверное будет IDisposable :-)

Из общедоступных практических примеров использования собственных интерфейсов:

• Простой интерфейс, описывающий всего один метод.
  
  

  interface ILoginForm
  {
  
    void WebDocumentLoaded(System.Windows.Forms.WebBrowser webBrowser, Uri url);
  
  }

  
  
  В проекте 100500 форм. Для некоторых форм может потребоваться индивидуальная обработка результатов, как здесь. А для других - нет. Все формы наследуются от базового класса, в котором я могу проверить, реализует текущий экземпляр интерфейс с индивидуальным обработчиком результатов или нет, и вызвать его.
  
  

  if (typeof(ILoginForm).IsAssignableFrom(this.GetType()))
  {
    this.CanLogin = false;
    Debug.WriteLine("ILoginForm", "LoginForm");
    ((ILoginForm)this).WebDocumentLoaded(this.webBrowser1, e.Url);
  }

  
  
  
• Вот другой пример интерфейса.
  
  

  export interface ILocalization {
  
    Loading: string;
  
    LoadingFileContents: string;
  
    // ...
  }

  
  Файлы с ресурсами локализации реализуют этот интерфейс.
  
  

  export class RU implements ILocalization {
  
    public Loading: string = 'Загрузка...';
  
    public LoadingFileContents: string = 'Получение содержимого файла...';
  
    // ...
  }

  
  Это просто упрощает работу с кодом и больше ничего.
  
  
  
  Можно было бы использовать обычные текстовые ключи, но тогда программистам пришлось бы постоянно смотреть, какие есть ключи, делать много лишних движений и вероятность ошибок возрастает.
  
  
  
• Еще пример интерфейса для вспомогательных классов работы с базами данных. Он просто описывает, каким должен быть класс.
  
  

  interface IDBClient
  {
      
    public function ExecuteNonQuery();
    public function ExecuteScalar();
    public function GetRow();
    // ...
  
  }

  
  А толку от этого никакого.
  
  Интерфейсы для слоев взаимодействия с БД я делаю частенько, с замахом на замену СУБД, но сделать это красиво в любом случае не получится, все равно придется вносить корректировки при изменении источника данных, так что практической пользы от таких интерфейсов мало, но иногда она есть, только для других целей.
  
  
• А вот тут я реализовал множество готовых интерфейсов, чтобы получить нужные свойства и поведение класса. Например, интерфейс IConvertible позволяет адекватно реагировать на Convert.To*. Интерфейс ISerializable позволяет описать правила сериализации экземпляра класса. И т.п.
  
  

  // реализация метода ToInt32
  public int ToInt32(IFormatProvider provider)
  {
    // если пусто, возвращаем ноль
    if (!this.HasValue) { return 0; }
    // если что-то есть, извлекаем числа и пробуем вернуть int32
    return Convert.ToInt32(OAuthUtility.GetNumber(this.Data));
  }

  
  
  
• Вот пример, где можно было использовать интерфейсы, но я принял решение в пользу базовых классов (на раннем этапе). Некоторые поставщики OAuth позволяют обновлять маркер доступа и/или отзывать его, но не все. В базовом классе нижнего уровня для определениях этих особенностей я сделал два свойства, причем даже не абстрактных.
  
  

  public bool SupportRevokeToken { get; protected set; }
  public bool SupportRefreshToken { get; protected set; }

  
  Клиенты, которым нужны эти свойства, задают их в конструкторе, выглядит это так.
  
  

  public GoogleClient(string clientId, string clientSecret) : base(/*...*/)
  {
    // ...
    base.SupportRevokeToken = true;
    base.SupportRefreshToken = true;
  }

  
  Не очень красиво, но ошибкой это назвать нельзя. Если бы я использовал интерфейсы, то для отзыва и обновления маркера мне бы пришлось делать два разных интерфейса, в каждом по одному bool свойству, либо пустых (но с явно определенным свойством для других программистов все было бы очевидней; это тоже спорный вопрос). Можно было пойти дальше и измельчить на интерфейсы другие особенности, но это было бы плохим решением, т.к. программистам пришлось бы указывать портянку интерфейсов, а потом писать много кода. С базовыми классами код писать не нужно, даже не нужно вникать в то, как это работает; в большинстве случаев достаточно просто выполнить простую конфигурацию дочернего класса в конструкторе. Но я не могу утверждать на 100%, что это лучшее решение для данного случая.
  
  
• Пример, где ReactJS и TypeScript заставляют клепать интерфейсы и я этому совсем не рад.
  
  

  export interface ILoginState {
  
    Username?: string;
    Password?: string;
  
    // ...
  
  }
  
  export default class Index extends Page<any, ILoginState> {
  
    constructor() {
  
      this.state = {
        Username: '',
        Password: ''
      };
  
    }
  
    // ...
  
  }

  
  Можно забить и использовать анонимные типы, но для порядка и удобства работы с кодом придется открывать собственный завод по производству интерфейсов :-)
  
  

С Windows Forms нужно быть готовым к разного рода фокусам со стороны Visual Studio.
Даже при использовании систем контроля версий, порой приходится повозиться с подлянками в виде пропавших картинок или дочерних элементов в каком-нибудь меню или ToolStrip. Многие подобные случаи можно поправить руками, путем ручного исправления файлов Designer, но не всегда. Чем сложнее форма, тем выше риск того, что дизайнер студии что-нибудь сломает; всегда нужно быть к этому готовым.

1. Раз появился такой вопрос, то видимо Ctrl + Z точно уже не поможет. Это первое, что нужно было сделать.

2. Если форма не была сохранения, то для отката изменений можно было бы её просто закрыть без сохранения. Но опять же, это нужно было делать сразу, при возникновении проблемы и если обычный откат назад (Ctrl + Z) не помог.

3. Если не используется система контроля версий, то нужно регулярно делать резервные копии исходного кода. Использование системам контроля версий будет удобней. Но даже при использовании систем контроля версий, следует регулярно делать резервные копии, и резервные копии резервных копий.

4. Если есть сборка нужного состояния программы (или приблизительно этому состоянию) и над пропавшим интерфейсом велась работа в поте лица, без перерывов на обед и сон, и все очень сложно и не хочется повторять этот героический поступок, то можно декомпилирвать предыдущую сборку и выдернуть код описания интерфейса из нее. Например, при помощи dotPeek.

Описание элементов формы, по умолчанию, находятся в файлах Designer. Например, элементы Form1 можно найти в файле Form1.Designer.cs. Иногда у элементов могут просто потеряться ссылки на родителей. Случай случайного удаления элемента и отката назад (Ctrl + Z) как раз-таки может привести к подобному поведению. Код в файле Designer обычно остается и ссылки можно поправить руками. Как правило, речь идет о добавлении строчек кода вида: this.родительскийЭлемент.Controls.Add(this.дочернийЭлемент). Главное понимать, что от чего отвалилось и что к чему нужно привязать. Если не понимать, то можно сделать хуже :-) (не стоит забывать про создание резервных копий). После внесения изменений в код дизайнера, следует переоткрыть конструктор форм (в идеале, перед внесением изменений в *.Designer.cs, конструктор форм (визуальный редактор форм) лучше закрыть).

Если элемент удален полностью и использовать восстановление из предыдущей сборки, то в декомпилированном коде нужно будет найти класс формы, а в нем метод InitializeComponent. У DataGridView, каждая колонка и строка (при наличии) будут являться отдельными элементами, нужно найти и перенести весь код описания этих элементов. Как правило, для каждого отдельного элемента, установка значений свойствам в коде идет последовательно. Дочерние элементы могут идти в разброс, по именам элементов можно более ли менее понять, что к чему (если стандартные имена у элементов менялись на собственные, то проблем с поиском возникнуть не должно).

Значения полей readonly можно менять динамически, в конструкторе класса. Последующие изменения невозможны.

public class MyClass
{

  public readonly int Value = 0;

  public MyClass()
  {
    this.Value = 123;
  }

}

Для чего это использовать - зависит от фантазии.

Например, можно создать класс User и сделать readonly поле, содержащее идентификатор пользователя. Таким образом, идентификатор пользователя можно будет указать только при инициализации класса и, в последующем, изменить его будет невозможно. Это позволит избежать проблем в логике, которые еще предстоит придумать :-)

Если сравнивать со свойствами и константами, то значения readonly свойств могут меняться в процессе жизненного цикла класса. Значения readonly полей, как уже было сказано ранее, можно указывать только при объявлении и в конструкторе класса.

Значения констант являются фиксированными и изменять их программно невозможно. Количество типов для констант ограничено, в то время как поля могут иметь любой тип. Константы являются статическими, а поля не обязаны быть таковыми. В этом плане, readonly поля более гибкие, чем константы.

В дополнение, немного кода (Console Application):

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Net;
using System.Timers;
using System.Threading;

namespace ConsoleApplication20
{

  class Program
  {
    static void Main(string[] args)
    {
      // создаем экземпляр класса
      var t = new Toster(199065);
      // выводим значение константы ProjectName
      // доступ только через Toster
      Console.WriteLine(Toster.ProjectName);
      // доступа к локальным константам здесь нет
      // Toster.CounterPattern
      // t.CounterPattern

      // выводим заголовок вопроса
      Console.WriteLine(t.Title);

      // бесконечность - не предел!
      while (true)
      {
        // t.Id = 123;
        // мы не можем поменять идентификатор
        // следовательно, этот код, логически, будет работать правильно

        // выводим число ответов
        Console.WriteLine("Ответов: {0}", t.AnswersCount);

        // t.AnswersCount = 123
        // мы не можем менять значение readonly свойства,
        // но оно может меняться внутри экземпляра класса

        // пауза 10 сек.
        Thread.Sleep(10000);
      }
    }
  }

  public class Toster
  {

    // публичная константа, доступ через Toster
    public const string ProjectName = "Тостер";

    // локальная константа, доступна только в рамках этого класса
    const string CounterPattern = "<span class=\"section-header__counter\" role=\"answers_counter\">";

    // публичные поля только для чтения
    // значение может быть установлено в конструкторе
    public readonly string Title = "Нет данных";
    public readonly int Id = 0;
    
    // свойство только для чтения
    // значение может меняться в процессе жизни экземпляра класса
    // при помощи локальной переменной
    private int _AnswersCount = 0;
    public int AnswersCount
    {
      get
      {
        return _AnswersCount;
      }
    }

    // это просто таймер
    private System.Timers.Timer Timer = null;

    // а это конструктор<s>, но не Lego</s>
    public Toster(int id)
    {
      if (id <= 0) { return; }
      
      // получаем вопрос
      var web = new WebClient();
      web.Encoding = Encoding.UTF8;
      var result = web.DownloadString(String.Format("https://toster.ru/q/{0}", id));
      // из шаблона url тоже можно сделать константу
      // либо в классе можно сделать readonly свойство, 
      // которое будет на лету формировать итоговый адрес:
      // return String.Format("https://toster.ru/q/{0}", this.Id)

      // устанавливаем значения для полей
      this.Id = id;
      this.Title = WebUtility.HtmlDecode
      ( 
        result.Substring
        (
          result.IndexOf("<title>") + "<title>".Length,
          result.IndexOf("</title>") - result.IndexOf("<title>") - "<title>".Length
        )
      );
      // выдергиваем число ответов на вопрос
      this.ParseAnswersCount(result);

      // запускаем периодическую проверку <s>Менделеева</s>
      Timer = new System.Timers.Timer(10000);
      Timer.Elapsed += Timer_Elapsed;
    }
    
    // обработчик истечения интервала времени 
    private void Timer_Elapsed(object sender, EventArgs e)
    {
      var web = new WebClient();
      web.Encoding = Encoding.UTF8;
      var result = web.DownloadString(String.Format("https://toster.ru/q/{0}", this.Id));
      this.ParseAnswersCount(result);
    }

    // выдергиватель количества ответов
    private void ParseAnswersCount(string value)
    {
      int startstart = value.IndexOf("Ответы на вопрос");
      int start = value.IndexOf(CounterPattern, startstart) + CounterPattern.Length;
      int len = value.IndexOf("</span>", start) - start;
      _AnswersCount = Convert.ToInt32(value.Substring(start, len));
    }
    
  }

}

Рекурсия:

private void button1_Click(object sender, EventArgs e)
{
  // создаем меню
  var menu = new MenuStrip();
  menu.Items.Add("Меню");

  // перебираем узлы
  foreach (TreeNode n in treeView1.Nodes)
  {
    // создаем элемент меню
    var menuItem = new ToolStripMenuItem();
    menuItem.Text = n.Text;
    // перебирем детей
    ConvertNodeToMenu(menuItem, n);
    // добавляем элемент в меню
    ((ToolStripMenuItem)menu.Items[0]).DropDownItems.Add(menuItem);
  }
      
  // добавляем меню на форму
  this.Controls.Add(menu);
}

private void ConvertNodeToMenu(ToolStripMenuItem menuParent, TreeNode node)
{
  foreach (TreeNode n in node.Nodes)
  {
    // создаем элемент меню
    var menuItem = new ToolStripMenuItem();
    menuItem.Text = n.Text;
    // перебираем детей
    ConvertNodeToMenu(menuItem, n);
    // добавляем элемент в меню
    menuParent.DropDownItems.Add(menuItem);
  }
}

Вариант с LINQ:

private void button1_Click(object sender, EventArgs e)
{
  // создаем меню
  var menu = new MenuStrip();
  menu.Items.Add("Меню");
  // берем первый элемент меню
  var menuItem = (ToolStripMenuItem)menu.Items[0];
  // получаем узлы и добавляем в меню
  menuItem.DropDownItems.AddRange
  (
    treeView1.Nodes.Cast<TreeNode>().Select
    (
      n => new ToolStripMenuItem(n.Text, null, ConvertNodeToMenu(n))
    ).ToArray()
  );
  // добавляем меню на форму
  this.Controls.Add(menu);
}

private ToolStripMenuItem[] ConvertNodeToMenu(TreeNode node)
{
  return node.Nodes.Cast<TreeNode>().Select
  (
    n => new ToolStripMenuItem(n.Text, null, ConvertNodeToMenu(n))
  ).ToArray();
}

На Windows XP должен быть установлен .NET Framework. В данном случае, версия 2.0. Также может потребоваться Service Pack 3.

Лучше ниже .NET Framework 3.5 не использовать.
И .NET Framework 4.0 под Windows XP вполне нормально работает, если установить. Версия 4.5 уже не поддерживается

.NET 2.0, если не изменяет память, по умолчанию не входил в состав Windows XP (если хотелось именно этого).

Можно разбить на массив по пробелу и выполнить сортировку массива, затем обратно склеить:

var value = "a ack fghjy fghfh asn";
// разбиваем на массив
var arr = value.Split();
// сортируем массив
Array.Sort(arr);
// склеиваем массив в строку
string result = String.Join(" ", arr);
// выводим результат
Console.WriteLine(result);

Или при помощи OrderBy:

Console.WriteLine(String.Join(" ", "a ack fghjy fghfh asn".Split().OrderBy(itm=>itm)));

Первый вариант оптимальней.
Посмотреть пример.