День триста восемьдесят шестой. #MoreEffectiveCSharp
2. По возможности делайте значимые типы неизменяемыми
Неизменяемые типы просты: после того, как они созданы, они являются постоянными. Если вы проверяете параметры в конструкторе, вы знаете, что объект находится в согласованном состоянии с момента создания. Вы не можете изменить внутреннее состояние объекта и нарушить согласованность. Тем самым вы избавляете себя от множества необходимых проверок. Кроме того, неизменяемые типы потокобезопасны, могут быть безопасно экспортированы и лучше работают в коллекциях на основе хешей.

На практике очень трудно сделать каждый тип неизменяемым. Вот почему эта рекомендация предназначена для атомарных неизменяемых значимых типов. Выделите среди ваших типов структуры, которые естественным образом образуют единую сущность. Например, Адрес - это единая сущность, состоящая из нескольких связанных полей. Изменение одного поля скорее всего означает изменения в других полях. А Клиент не является атомарным типом. Он, скорее всего, будет содержать много независимой друг от друга информации: адрес, имя и один или несколько телефонных номеров. Любая из этих частей информации может измениться независимо от других.
В атомарных типах скорее всего изменится всё содержимое, а изменение одного из полей - исключение.

Внутренние изменения состояния означают, что возможно нарушить инварианты объекта, по крайней мере, временно. Например, при изменении города скорее всего изменится индекс или область. Изменение их двумя последовательными присваиваниями выглядит безопасно, но предположим, что этот фрагмент является частью многопоточной программы. Любое переключение контекста после изменения города и до изменения индекса может привести к тому, что другой поток увидит несогласованное представление данных.

У вас однопоточная программа? Тогда представьте, что после изменения города возникло исключение. Внесена лишь часть изменений, и объект остался в недопустимом состоянии. В итоге как для потоковой безопасности, так и для защиты от ошибок, пришлось бы добавлять массивный код проверки целостности объекта, который бы только увеличивался по мере эволюции приложения.

Чтобы создать неизменяемый тип, помимо запрета на изменение состояния в интерфейсе типа, необходимо убедиться, что в нем нет дыр, которые позволили бы клиентам изменять его внутреннее состояние. Структуры не поддерживают наследования, поэтому можно не защищаться от изменяемых полей в производных типах. Но нужно следить за любыми полями ссылочного типам в неизменяемом типе. Например, массив – ссылочный тип. Если массив разместить в поле readonly, то само поле (ссылка на массив) будет неизменяемо, но отдельные элементы массива всё равно можно изменить.
Чтобы исключить эту возможность, нужно делать защищённую копию массива, либо можно использовать класс ImmutableArray из пространства имен System.Collections.Immutable.

Сложность типа определяет, какую из трех стратегий использовать для инициализации неизменяемого типа:
1. Определить разумный ограниченный набор конструкторов. Это часто является самым простым подходом.
2. Создать фабричные методы для инициализации. Фабрики облегчают создание часто используемых значений. Например, тип Color следует этой стратегии для инициализации системных цветов. Статические методы Color.FromKnownColor() и Color.FromName() создают объект типа из значения предопределённого системного цвета.
3. Создать изменяемый вспомогательный класс для случаев, когда необходимы многоэтапные операции для полного создания неизменяемого типа. Примером такого вспомогательного класса является System.Text.StringBuilder для создания строк.

Неизменяемые типы проще как при написании кода, так и при его обслуживании. Не спешите слепо лепить аксессоры get и set для каждого свойства вашего типа. Первоначальным выбором для типов, хранящих данные, должны быть неизменяемые, атомарные значимые типы. Затем вы легко сможете построить более сложные структуры из этих объектов.

Источник: Bill Wagner “More Effective C#”. – 2nd ed. Глава 3.

День триста девяносто первый. #MoreEffectiveCSharp
3. Использование значимых и ссылочных типов
Вы должны решить, как будут вести себя все экземпляры вашего типа. Это важное решение, которое нужно принять при создании, потому что изменение структуры на класс может поломать довольно много кода самым непредсказуемым образом.

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

Например, тип используется как возвращаемое значение из метода:

private MyData myData;
public MyData Foo() => myData;
MyData v = Foo();
TotalSum += v.Value;

Если MyData — значимый тип, содержимое возврата копируется в переменную v. А если MyData — ссылочный тип, то экспортируется ссылка на внутреннюю переменную. Вы нарушаете принцип инкапсуляции, что может позволить клиентам изменять объект по ссылке, обходя ваш API. Другой вариант:

public MyData Foo2 () => myData.CreateCopy();

Теперь v — это копия исходных данных myData. В куче создаются два объекта. Исчезла проблема раскрытия внутренних данных, но мы создали дополнительный объект в куче. В общем, это неэффективно. Типы, которые используются для экспорта данных с помощью открытых методов и свойств, должны быть значимыми типами.

Теперь немного подробнее рассмотрим, как эти типы хранятся в памяти, а также вопросы производительности, связанные с моделями хранения:

public class C {
  private MyType a = new MyType();
  private MyType b = new MyType();
  …
}
C c = new C();

Сколько объектов создано? Насколько они большие? Это зависит. Если MyType — структура, выделен один объект, размер которого в два раза больше размера MyType. А если MyType — класс, выделено 3 объекта: для типа C (8 байт в 32-разрядной системе) и 2 для типа MyType. Разница возникает из-за того, что структуры хранятся внутри объекта, а каждая переменная ссылочного типа содержит ссылку, и требует выделения дополнительного места в хранилище. Это особенно важно, если вы собираетесь выделить место под массив. Массив структур выделится за 1 раз, массив ссылочных типов изначально будет заполнен null, но потребует дополнительного выделения места под каждый элемент при его инициализации.

Решение использовать структуру или класс является очень важным. Изменение структуры на класс в готовом коде влечёт за собой неприятные последствия. Допустим вы создали структуру работника, хранящую размер заработной платы. Затем вы решаете, что могут быть разные классы сотрудников: продавцы получают комиссионные, а менеджеры получают бонусы. Вы решаете изменить структуру на класс. Это нарушит большую часть клиентского кода, использующего структуру. Возврат по значению становится возвратом по ссылке. Параметры, которые передавались по значению, теперь передаются по ссылке. Помимо хранения элементов данных, которые определяют сотрудника, вы добавили обязанности: расчёт зарплаты. Обязанности — это ответственность классов. Классы могут легко определять полиморфные реализации общих обязанностей; структуры должны ограничиваться хранением значений.

Документация по .NET рекомендует рассматривать размер типа как определяющий фактор между типами значений и ссылочными типами. На самом деле, гораздо лучшим фактором является способ использования типа. Если вы ответите «да» на все эти вопросы, создавайте структуру:
1. Основная обязанность типа - хранение данных?
2. Можно ли сделать этот тип неизменяемым?
3. Ожидается, что тип будет маленьким?
4. Открытый интерфейс типа содержит только свойства для доступа к данным?
5. У типа никогда не будет подклассов?
6. Тип никогда не будет использоваться полиморфно?
Если вы сомневаетесь относительно ожидаемого использования типа, используйте ссылочный тип.

Источник: Bill Wagner “More Effective C#”. – 2nd ed. Глава 4.

День четырёхсотый. #MoreEffectiveCSharp
5. Убедитесь, что 0 является допустимым состоянием для значимых типов
Инициализация по умолчанию в .NET устанавливает все значения в 0. Невозможно запретить другим программистам создавать экземпляр значимого типа со значениями по умолчанию. Сделайте 0 значением по умолчанию для типа.

Особый случай - перечисления. Никогда не создавайте перечисление, которое не содержит 0 в качестве допустимого значения:

public enum Planet
{
  // Явно назначенные значения
  // По умолчанию начинаются с 0
  Mercury = 1,
  Venus = 2,
  Earth = 3,
  …
}
Planet sphere = new Planet();
var anotherSphere = default(Planet);

И sphere, и anotherSphere имеют значение 0, которое не является допустимым. Любой код, предполагающий, что перечисления ограничены определённым набором значений, возможно, будет работать неверно.

Кроме того, это влияет на объекты, содержащие перечисление:

public struct PlanetData
{
  private Planet planet;
  private double magnitude; //яркость
}
var data = new PlanetData();

data имеет яркость 0, что нормально, но значение планеты недопустимое.

✅ По возможности выберите наилучшее значение по умолчанию для 0, либо добавьте специальное неинициализированное значение None = 0, которое можно будет изменить позже.
✅ Для перечислений, являющихся битовыми флагами, убедитесь, что 0 является действительным значением и означает «отсутствие всех флагов». Подробнее о битовых флагах.
⚠️ Перечисления - лишь обёртка для набора целочисленных констант. Если это не обеспечивает нужную вам абстракцию, следует рассмотреть возможность использования другой конструкции языка.

Другая распространённая проблема состоит в инициализации ссылочных полей структур:

public struct LogMessage
{
  public int ErrLevel;
  public string Message;
}
LogMessage myMsg = new LogMessage();

myMsg содержит null в поле Message. Невозможно принудительно инициировать поле другим значением, но можно локализовать проблему, используя свойства. Добавьте логику в свойство, чтобы возвращать пустую строку вместо null:

public struct LogMessage
{
  public int ErrLevel;
  private string msg;
  public string Message
  {
    get => msg ?? string.Empty; 
    set => msg = value;
  }
}

Используйте свойство и в коде типа. Это позволит локализовать проверку на null в одном месте. Аксессор свойства почти наверняка будет встроен при компиляции, поэтому вы получите эффективный код и сведёте к минимуму ошибки.

Источник: Bill Wagner “More Effective C#”. – 2nd ed. Глава 5.

День четыреcта пятый. #MoreEffectiveCSharp
6. Убедитесь, что свойства ведут себя как данные
Свойства ведут себя двояко. Снаружи они похожи на простой доступ к данным, однако изнутри это методы. Такое поведение может вызвать соблазн создать свойство, выполняющее некоторую работу перед выдачей результата. Однако имейте в виду, что клиенты класса ждут от свойств некоторого определённого поведения:
1. Последующие вызовы аксессора (get) без каких-либо промежуточных действий должны приводить к тому же результату (понятно, что это не относится к случаю изменения свойства другими потоками).
2. Аксессор свойства не будет выполнять большую работу. Доступ к данным никогда не должен быть дорогой операцией. Аналогично, методы доступа к набору свойств, вероятно, будут выполнять некоторую проверку, но их вызов не должен быть дорогим. Например, в цикле
for(int i=0;i<arr.Length;i++)
если бы свойство Length считало количество элементов на каждой итерации, такой простой цикл выполнялся бы в квадратичное время, и никто бы его не использовал.

Соответствовать таким ожиданиям клиентов не сложно:
1. Используйте автосвойства.
2. Реализуйте проверку значения свойства в мутаторе (set), а не в аксессоре (get). Таким образом она будет выполняться 1 раз при записи, а не при каждом чтении значения.
3. Простые математические расчёты (расстояние до точки по координатам или площадь фигуры) никак не влияют на производительность, поэтому их можно безболезненно включить в аксессор.

Однако, если расчёт значения дорог, нужно продумать доступ к нему:

// Плохая реализация
public class MyType {
  public string Name => GetFromDB();
}

Пользователи не ожидают, что доступ к свойству потребует обращения к базе данных. Поэтому API нужно изменить. Есть несколько способов:
1. Получение однократно и сохранение в кэше

public class MyType {
  private string name;
  public string Name => (name != null) ? 
    name : GetFromDB();
}

*GetFromDB в этом случае устанавливает значение name.
2. Аналогичный способ с использованием типа Lazy<T>:

public class MyType {
  private Lazy<string> lazyName;
  public MyType() {
    lazyName = new Lazy<string>(() => GetFromDB());
  }
  public string Name => lazyObjectName.Value;
}

Это хорошо работает, когда свойство Name требуется только изредка. Вы не извлекаете значение, если оно не нужно. Но первый обратившийся к нему «страдает за всех». Если к свойству обращаются часто, можно рассмотреть вариант получения значения в конструкторе сразу при создании экземпляра.

3. Предыдущие примеры предполагают, что значение в БД никто не изменяет. В противном случае, если требуется как получать, так и изменять значение в БД, доступ лучше реализовать через методы с понятными именами (например, LoadFromDatabase и SaveToDatabase), чтобы клиентам был очевиден объём работы, требующийся для этого.

Наконец, имейте в виду, что отладчики могут автоматически вызывать методы доступа к свойству для отображения значения при отладке. Если аксессор выбрасывает исключение, занимает много времени или изменяет внутреннее состояние приложения, это усложнит ваши сеансы отладки. В этом случае в Visual Studio можно использовать трюк «Определение значения без побочных эффектов».

Источник: Bill Wagner “More Effective C#”. – 2nd ed. Глава 6.

День четыреста тридцать первый. #MoreEffectiveCSharp
7. Ограничивайте Область Действия Типа, Используя Анонимные Типы
Для создания пользовательских типов, представляющих объекты и структуры данных программы, вы можете выбрать классы, структуры, кортежи или анонимные типы. Классы и структуры настолько богаты в смысле выражения ваших замыслов, что заставляют многих разработчиков выбирать их, не рассматривая другие возможности. Вы можете написать более читаемый код, используя более простые конструкции: анонимные типы или кортежи.

Анонимные типы — это генерируемые компилятором неизменяемые ссылочные типы, которые можно объявить так:

var point = new {X = 5, Y = 67};

Вы указали компилятору, что вам нужен
- новый закрытый (sealed) класс,
- этот новый тип является неизменяемым,
- тип имеет два открытых свойства только для чтения X и Y.

Преимущества
1. Код короче и меньше подвержен ошибкам.
2. Область действия анонимного типа ограничена методом, в котором он определён. Таким образом тип не загрязняет пространство имён, а ясно показывает другим разработчикам, что он используется для промежуточных вычислений только в пределах этого единственного метода.
3. Для обычных классов вы не можете задавать значения свойств только для чтения через инициализатор объекта, так как это позволяют делать анонимные типы.
4. Компилятор создаёт оптимизированный код. Всякий раз, когда вы создаёте такой же анонимный тип, компилятор не генерирует новый тип, а использует уже существующий*.
*Примечание: 1) очевидно, что это происходит, только если несколько копий анонимного типа объявлены в одной сборке, 2) имена, типы и порядок свойств анонимных типов должны совпадать.
5. Анонимные типы могут использоваться как составные ключи. Предположим, что вам нужно сгруппировать клиентов по продавцу и почтовому индексу. Вы можете выполнить запрос:

var query = from c in customers
  group c by new { c.SalesRep, c.ZipCode };

Он создаст словарь, в котором ключами будут пары SalesRep и ZipCode, а значениями - списки клиентов.

Очевидным недостатком использования анонимных типов является то, что вы не знаете названия типа, а значит не можете использовать его в качестве параметра метода или возвращаемого значения. Тем не менее, есть способы работы с отдельными объектами или последовательностями анонимных типов, используя обобщённые методы и лямбда выражения. Например, имея обобщённый метод преобразования:

static T Transform<T> (T e, Func<T, T> func) {
  return func(e);
}

можно удвоить значения X и Y для точки, передав анонимный тип и функцию преобразования в метод Transform:

var p1 = new { X = 5, Y = 67 };
var p2 = Transform(p1, (p) => new { X=p.X*2, Y=p.Y*2 });

Кортежи являются изменяемыми значимыми типами с открытыми полями.

var point = (X: 5, Y: 67);

Создание экземпляра кортежа не генерирует новый тип, как создание нового анонимного типа. Вместо этого создаётся одна из структур ValueTuple (их несколько в зависимости от количества элементов кортежа). ValueTuple содержит методы проверки на равенство, сравнение и метод ToString(), который печатает значение каждого поля кортежа.
Совместимость типов C# обычно основана на имени типа и называется номинативной типизацией. Кортежи используют структурную типизацию, а не номинативную, чтобы определить, относятся ли разные объекты к одному и тому же типу. Кортежи полагаются на свою «форму», а не на имя для определения конкретного типа. Таким образом любой кортеж, который содержит 2 целых числа, будет того же типа, что кортеж point выше. Заметки по использованию кортежей.

Источник: Bill Wagner “More Effective C#”. – 2nd ed. Глава 7.

День четыреста сорок четвёртый. #MoreEffectiveCSharp
8. Различные Концепции Равенства. Начало
Когда вы создаёте собственные типы (классы или структуры), вы определяете, что означает равенство для этого типа. C# предоставляет четыре метода, которые определяют, «равны» ли два разных объекта:
1.

 static bool ReferenceEquals (object left, object right);

2.

 static bool Equals (object left, object right);

3.

 virtual bool Equals(object right);

4.

 static bool operator ==(MyClass left, MyClass right);

Первые два переопределять не следует. Чаще всего переопределяют экземплярный метод Equals() для обеспечения семантики равенства в типе. Также иногда переопределяется оператор ==, обычно для структур. Между этими четырьмя методами есть взаимосвязь, поэтому при изменении одного вы можете повлиять на поведение других. Кроме того, типы, переопределяющие Equals(), должны реализовывать IEquatable<T>. Типы, которые реализуют семантику сравнения входящих в них элементов (массивы, кортежи), должны реализовывать интерфейс IStructuralEquatable.

1. Object.ReferenceEquals() возвращает true, если две ссылки ссылаются на один и тот же объект. Независимо от того, являются ли сравниваемые типы ссылочными типами или типами значений, этот метод всегда проверяет идентичность объекта, а не его содержимое. ReferenceEquals() всегда возвращает false для значимых типов из-за того, что происходит упаковка значений.

2. Object.Equals() проверяет, равны ли две ссылки, когда вы не знаете тип времени выполнения двух аргументов. Как он это делает? Он делегирует проверку равенства одному из переданных ему параметров. Метод реализован примерно так:

public static bool Equals(object left, object right) {
  // проверка ссылочного равенства
  if (Object.ReferenceEquals(left, right) )
    return true;
  // вариант с двумя null учтён выше
  if (Object.ReferenceEquals(left, null) ||
      Object.ReferenceEquals(right, null))
    return false;
  
  return left.Equals(right);
}

Как видите, метод делегирует проверку равенства экземплярному методу Equals() левого аргумента, таким образом используя правила проверки на равенство этого типа.

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

Прежде, чем обсудить переопределение других двух методов, кратко рассмотрим математические свойства равенства. Вы должны убедиться, что ваше определение и реализация соответствуют ожиданиям других программистов. Модульные тесты для типов, которые переопределяют Equals(), должны гарантировать, что реализация соблюдает эти правила:
- Рефлексивность (любой объект равен самому себе): независимо от типа, a = a всегда верно.
- Симметричность (порядок не имеет значения): если a = b, то b = a, если a <> b, то b <> a).
- Транзитивность: если a = b и b = c, то a = c.

Продолжение следует…

Источник: Bill Wagner “More Effective C#”. – 2nd ed. Глава 9.

День четыреста сорок пятый. #MoreEffectiveCSharp
8. Различные Концепции Равенства. Продолжение
Первая часть
3. Экземплярный метод Equals() переопределяют, когда поведение по умолчанию не соответствует семантике типа. Метод Object.Equals() по умолчанию ведёт себя точно так же, как Object.ReferenceEquals(), то есть проверяет ссылочное равенство. Но, например, System.ValueType (базовый класс для всех типов значений) переопределяет Object.Equals(): две переменные значимого типа равны, если они одного типа и имеют одинаковое содержимое. К сожалению, базовая реализация метода ValueType.Equals() не всегда эффективна. Если структура содержит ссылочный тип, для сравнения используется рефлексия:

struct StructNoRef {
  public int X { get; set; }
  public int Y { get; set; }
}
struct StructWithRef {
  public int X { get; set; }
  public int Y { get; set; }
  public string Description { get; set; }
}
…
var stopwatch = new Stopwatch();
var data1 = new StructNoRef();
var data2 = new StructNoRef();
stopwatch.Start();
for (int i = 0; i < 1000000; i++)
  data1.Equals(data2);
stopwatch.Stop();
WriteLine("StructNoRef: " + stopwatch.ElapsedMilliseconds);

stopwatch.Reset();
var data3 = new StructWithRef();
var data4 = new StructWithRef();
stopwatch.Start();
for (int i = 0; i < 1000000; i++)
  data3.Equals(data4);
stopwatch.Stop();
WriteLine("StructWithRef: " + stopwatch.ElapsedMilliseconds);

Вывод:

StructNoRef: 66
StructWithRef: 1077

Проверка на равенство довольно часто вызывается в программах, поэтому её производительность не стоит игнорировать. Почти всегда вы можете написать намного более быстрое переопределение Equals() для любой структуры. Переопределим метод для StructWithRef:

struct StructWithRef {
  /// … 
  public override bool Equals(object obj) {
    if (!(obj is StructWithRef))
      return false;
    var other = (StructWithRef)obj;
    return X == other.X && 
      Y == other.Y && 
      Description == other.Description;
  }
}

Вывод:

StructNoRef: 61
StructWithRef: 81

Окончание следует…

Источники:
- Bill Wagner “More Effective C#”. – 2nd ed. Глава 9.
- https://codewithshadman.com/csharp-data-types-and-object-tips/

День четыреста сорок шестой. #MoreEffectiveCSharp
8. Различные Концепции Равенства. Окончание
Первая часть, Вторая часть
Для ссылочных типов переопределённый метод Equals должен следовать предопределенному поведению, чтобы избежать странных сюрпризов для пользователей класса. Кроме того, нужно реализовать интерфейс IEquatable<T>. Вот стандартный шаблон:

public class Foo : IEquatable<Foo> {
  public override bool Equals(object right) {
    if (object.ReferenceEquals(right, null))
      return false;
    if (object.ReferenceEquals(this, right))
      return true;
    if (this.GetType() != right.GetType())
      return false;
    
    return this.Equals(right as Foo);
  }
  // IEquatable<Foo>
  public bool Equals(Foo other) { … }
}

Метод не должен генерировать исключения, т.к. это не имеет особого смысла. Две ссылки либо равны, либо не равны, что может пойти не так? Просто верните false. Сначала проверяется, не является ли аргумент null (CLR не даст нам вызвать a.Equals(b), если a == null, будет выброшено NullReferenceException). Далее проверяется равенство ссылок. Обратите внимание, что для проверки принадлежности объектов к одному типу, вызывается GetType. Дело в том, что недостаточно проверить, можно ли привести right к типу Foo (например, if(right is Foo) {…}, как в примере из предыдущего поста со структурами). right может быть производным типом от Foo, значит его можно привести к базовому типу и проверка вернёт true. Однако базовый класс нельзя привести к производному. Таким образом нарушается правило симметричности равенства: a.Equals(b) и b.Equals(a) будут давать разные результаты. Далее метод делегирует проверку на равенство безопасному к типам методу Equals(Foo) - реализации интерфейса IEquatable<Foo>.

Примечание: переопределение метода Equals() также предполагает переопределение метода GetHashCode(). Об этом в будущих постах.

4. Оператор == переопределяется для значимых типов по тем же причинам, что и метод Equals() и обычно просто вызывает этот метод. Что касается ссылочных типов, в этом случае оператор == переопределяется редко, т.к. предполагается, что для всех ссылочных типов он реализует семантику проверки на ссылочное равенство.

Наконец, IStructuralEquatable реализуют System.Array и классы Tuple<>. Он позволяет им сравнивать объекты друг с другом, не заботясь о деталях семантики сравнения содержащихся в них элементов, потому что реализация метода Equals(Object, IEqualityComparer) принимает компаратор, который отвечает за это.

Источник: Bill Wagner “More Effective C#”. – 2nd ed. Глава 9.

День четыреста пятьдесят первый. #MoreEffectiveCSharp
9. Тонкости GetHashCode(). Начало
GetHashCode() – одна из тех функций, которую, по возможности, не стоит реализовывать самостоятельно. Она используется только в одном месте: для определения значения хеш-функции для ключей в коллекциях на основе хеша (обычно это HashSet<T> или Dictionary<K,V>). Есть ряд проблем с реализацией GetHashCode() в базовом классе. Для ссылочных типов она работает, но не очень эффективно. Для типов значений есть специальные оптимизации, если он не имеет ссылочных полей, в противном случае функция работает медленно и не всегда верно. Но дело не только в этом. Скорее всего, вы не сможете самостоятельно реализовать GetHashCode() и эффективно, и правильно.

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

В .NET каждый объект имеет хеш-код, определённый в System.Object.GetHashCode(). Любая перегрузка GetHashCode() должна следовать трём правилам:
1. Если два объекта равны (как определено экземплярным методом Equals()), они должны генерировать один и тот же хеш-код.
Версия оператора == в System.Object проверяет идентичность объектов. GetHashCode() возвращает внутреннее поле - идентификатор объекта, и это правило работает. Однако, если вы переопределили метод Equals(), нужно переопределить и GetHashCode(), чтобы обеспечить соблюдение правила.

2. Для любого объекта A хеш-код должен быть инвариантен. То есть, независимо от того, какие методы вызываются на объекте, A.GetHashCode() всегда должен возвращать одно и то же значение. К примеру, изменение значения поля не должно приводить к изменению хэш-кода.

3. Хеш-функция должна генерировать равномерное распределение среди всех целых чисел для всех типичных входных наборов. Это более-менее соблюдается для System.Object.

Написание правильной и эффективной хэш-функции требует глубоких знаний о типе, чтобы обеспечить соблюдение правила 3. Стандартные версии не эффективны, потому что должны обеспечивать лучшее поведение по умолчанию, практически не зная вашего конкретного типа.

Для типов-значений стандартная версия GetHashCode возвращает хэш-код только первого ненулевого поля, смешивая его с идентификатором типа. Проблема в том, что в этом случае начинает играть роль порядок полей типа. Если значение первого поля экземпляров одинаково, то хэш-функция будет выдавать одинаковый результат. Таким образом, если большинство экземпляров типа имеют одинаковое значение первого поля, то производительность поиска по хэш-набору или хэш-таблице из таких элементов резко упадет (см. тест в статье на Хабре).

Окончание следует…

Источники:
- Bill Wagner “More Effective C#”. – 2nd ed. Глава 10.
- https://habr.com/ru/company/microsoft/blog/418515/

День четыреста пятьдесят второй. #MoreEffectiveCSharp
9. Тонкости GetHashCode(). Окончание
Для переопределения GetHashCode нужно наложить некоторые ограничения на тип. В идеале он должен быть неизменяемым. Посмотрим ещё раз на правила:
1. Если два объекта равны по методу Equals(), они должны возвращать одинаковый хэш. Следовательно, любые данные, используемые для генерации хеш-кода, также должны участвовать в проверке на равенство.

2. Возвращаемое значение GetHashCode() не должно изменяться. Допустим, у нас есть класс, в котором мы переопределили GetHashCode:

public class Customer {
  public Customer(string name) => Name = name;
  public string Name { get; set; }
  // другие свойства
  public override int GetHashCode() 
    => Name.GetHashCode();
}

Мы разместили объект Customer в HashSet, a затем решили изменить значение Name:

var cs = new HashSet<Customer>();
var c = new Customer("Ivanov");

cs.Add(c);
Console.WriteLine(
  $"{cs.Contains(c)}, всего: {cs.Count}");
c.Name = "Petrov";
Console.WriteLine(
  $"{cs.Contains(c)}, всего: {cs.Count}");

Вывод:

True, всего: 1
False, всего: 1

Хэш-код объекта изменился. Объект по-прежнему находится в коллекции, но теперь его невозможно найти. Единственный способ удовлетворить правилу 2 - определить хеш-функцию, которая будет возвращать значение на основе некоторого инвариантного свойства или свойств объекта. System.Object соблюдает это правило, используя идентификатор объекта, который не изменяется.

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

Microsoft предоставляет хороший универсальный генератор хэш-кодов. Просто скопируйте значения свойств/полей (соблюдая правила выше) в анонимный тип и хешируйте его:

public override int GetHashCode() 
  => new { PropA, PropB, PropC, … }.GetHashCode();

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

Для C# 7+ можно использовать кортеж. Это сэкономит несколько нажатий клавиш и, что более важно, выполняется исключительно на стеке (без мусора):

public override int GetHashCode()
  => (PropA, PropB, PropC, …).GetHashCode();

Источники:
- Bill Wagner “More Effective C#”. – 2nd ed. Глава 10.
- https://stackoverflow.com/questions/263400/what-is-the-best-algorithm-for-overriding-gethashcode

День четыреста шестьдесят шестой. #MoreEffectiveCSharp
10. Избегайте Операторов Приведения в Публичных API
Операторы приведения вводят своего рода взаимозаменяемость между классами. То есть один класс может быть заменён другим. Это может быть преимуществом: объект производного класса может быть заменён объектом его базового класса, как в классическом примере полиморфизма.

Когда вы определяете оператор преобразования для вашего типа, вы сообщаете компилятору, что ваш тип может быть заменён на целевой тип. Эти замены часто приводят к тонким ошибкам, потому что ваш тип, вероятно, не является идеальной заменой целевого типа. Методы, изменяющие состояние целевого типа, не будут отражаться на вашем типе. А если ваш оператор приведения возвращает временный объект, изменения и вовсе будут утеряны.

Рассмотрим объекты круг (Circle) и эллипс (Ellipse), производные от абстрактного класса фигуры (Shape). Допустим, вы решили сохранить эту иерархию классов, но вам может потребоваться использовать круг вместо эллипса в некоторых случаях (ведь каждый круг является эллипсом), и вы решили реализовать оператор приведения круга к эллипсу:

public class Circle : Shape {
  private Point center;
  private double radius;
  public Circle(Point c, double r) {
    center = c;
    radius = r;
  }
  static public implicit operator Ellipse(Circle c) {
    return new Ellipse(c.center, c.center, c.radius, c.radius);
  }
}

Оператор неявного приведения будет вызываться всякий раз, когда один тип необходимо преобразовать в другой тип. Оператор явного (explicit) приведения вызывается только когда программист явно использует оператор приведения:

Ellipse e = (Ellipse)circle.

Теперь, можно использовать Circle в любом месте, где ожидается Ellipse, и приведение произойдёт автоматически:

public static double ComputeArea(Ellipse e) 
  => e.R1 * e.R2 * Math.PI;
Circle c1 = new Circle(new Point(3.0, 0), 5.0f);
ComputeArea(c1);

Вот что подразумевалось под взаимозаменяемостью: круг можно использовать вместо эллипса, и всё работает. Однако рассмотрим следующий метод, «сплющивающий» эллипс:

public static void Flatten(Ellipse e) {
  e.R1 /= 2;
  e.R2 *= 2;
}
Circle c = new Circle(new Point(3.0, 0), 5.0);
Flatten(c);

Этот код не сработает. Выполнится неявное приведение, и метод Flatten() изменит новый временный объект эллипса, который тут же попадёт в мусор. Исходный круг c при этом не изменится.

Вместо приведения используйте конструктор, принимающий исходный тип в качестве параметра. Определим в классе Ellipse конструктор, принимающий Circle как параметр и создающий эллипс из круга. Тогда код выше будет выглядеть так:

Circle c = new Circle(new Point(3.0, 0), 5.0);
Flatten(new Ellipse(c));

Большинство программистов увидят проблему: любые модификации эллипса в методе Flatten() теряются. Они исправят проблему, создав новый объект:

Circle c = new Circle(new Point(3.0, 0), 5.0);
Ellipse e = new Ellipse(c);
Flatten(e);

Переменная e будет содержать сплющенный эллипс. Заменив оператор преобразования на конструктор, мы не потеряли никакой функциональности, а только сделали очевидным, что при приведении создаётся новый объект.

Источник: Bill Wagner “More Effective C#”. – 2nd ed. Глава 11.

День четыреста семьдесят первый. #MoreEffectiveCSharp
11. Используйте Необязательные Параметры, Чтобы Минимизировать Перегрузки Методов
C# позволяет указывать аргументы метода по позиции или по имени. Разработчики, вызывающие ваш API, могут использовать именованные параметры, хотите вы того или нет. Следующий метод:

private void SetName(string lastName, string firstName) {…}

можно вызвать с именованными параметрами:

SetName(lastName: "Иванов", firstName: "Иван");

Это гарантирует, что при прочтении этого кода не возникнет вопроса, находятся ли параметры в правильном порядке. Разработчики будут использовать именованные параметры всякий раз, когда это повышает читаемость кода (фактически, всегда, когда метод принимает несколько параметров одного типа).

Изменение имён параметров проявляется интересным образом. Имена параметров хранятся в MSIL только в месте вызова, но не в вызываемом коде. Вы можете изменить имена параметров и выпустить новую версию сборки, не нарушив работу её пользователей. Разработчики, использующие сборку, увидят проблему только когда решат перекомпилировать свой код, используя обновлённую версию. Существующие клиентские сборки продолжат работать правильно. Предположим, что вы изменили SetName():

public void SetName(string last, string first)

Вы можете скомпилировать и выпустить новую версию этой сборки. Любые сборки, которые вызывают этот метод, будут продолжать работать, но, когда разработчики сошлются на обновлённую сборку, следующий код больше не скомпилируется:

SetName(lastName: "Иванов", firstName: "Иван");

Применение именованных параметров совместно с необязательными параметрами (со значениями по умолчанию) позволяет клиенту API указывать только те параметры, которые он хочет переопределить. Это проще, чем использовать множество перегрузок. Например, метод:

public void SetName(string last = "Иванов", 
  string first = "Иван") {…}

можно вызвать, либо вообще без параметров:

SetName();

либо переопределив только имя:

SetName(first: "Олег");

При этом изменение значений по умолчанию параметров метода потребует перекомпиляции вызывающего кода для отражения изменений. Существующие вызывающие сборки продолжат использовать предыдущее значение по умолчанию.

Добавление параметров вызовет ошибку времени выполнения в клиентском коде. Необязательные параметры реализованы аналогично именованным параметрам. Вызывающий код будет содержать аннотации в MSIL, отражающие существование значений по умолчанию и их значения. Там эти значения будут использоваться для всех необязательных параметров, значения для которых не указаны явно. Следовательно добавление в метод параметров (даже со значениями по умолчанию) вызовет в клиентском коде ошибку времени выполнения. Однако добавление параметров со значениями по умолчанию не вызовет ошибку при перекомпиляции клиентского кода.

Итого:
- Для вашего первоначального релиза используйте необязательные и именованные параметры, чтобы предусмотреть любые комбинации параметров, которые ваши пользователи захотят использовать.
- При последующих изменениях создавайте перегрузки методов для добавления дополнительных параметров. Таким образом, существующие клиентские приложения продолжат работать.
- При последующих изменениях избегайте изменения имён параметров в открытых или защищённых методах. Теперь они являются частью вашего публичного интерфейса.

Источник: Bill Wagner “More Effective C#”. – 2nd ed. Глава 12.

День четыреста восемьдесят четвёртый. #MoreEffectiveCSharp
12. Ограничивайте Видимость Ваших Типов
Не каждый ваш тип должен быть публичным. Типам нужно давать наименьшую необходимую видимость для достижения вашей цели. Часто меньшую, чем кажется. Внутренние или приватные классы могут реализовывать публичные интерфейсы. Все клиенты могут получать доступ к функциональности, определённой в открытых интерфейсах и реализованной в закрытом типе. Обычно большинство программистов постоянно создают открытые классы, не задумываясь об альтернативах. Это очень просто, но лучше тщательно продумать, где будет использоваться новый тип. Он предназначен для всех клиентов или в основном используется внутри этой сборки? Многим классам достаточно быть внутренними, защищёнными, закрытыми или вложенными в другой класс. Чем меньше видимость, тем меньше мест, откуда можно получить доступ к коду, и меньше мест, которые потребуется изменить при обновлении системы.

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

Рассмотрим класс, который проверяет формат номера телефона (8(xxx)xxx-xx-xx):

public class PhoneValidator {
  public bool Validate(PhoneNumber ph) { … }
}

Всё работает хорошо, но спустя некоторое время требуется, чтобы проверялись и международные номера с кодом страны (+x(xxx)-xxx-xx-xx).
Вместо того, чтобы добавлять функциональность в этот класс, и использовать его напрямую, лучше уменьшить связанность между классами. Создадим интерфейс для проверки любого телефонного номера:

public interface IPhoneValidator {
  bool Validate(PhoneNumber ph);
}

Затем создадим внутренние классы для проверки местных и международных номеров, реализующие этот интерфейс:

internal class LocalPhoneValidator : IPhoneValidator {…}
internal class InternationalPhoneValidator : IPhoneValidator {…}

Наконец нужен фабричный метод для создания нужного класса в зависимости от типа номера телефона:

public static IPhoneValidator CreateValidator(PhoneTypes type) {
  switch (type) {
    case PhoneTypes.Local:
      return new LocalPhoneValidator();
    case PhoneTypes.International:
    default:
      return new InternationalPhoneValidator();
  }
}

Общую функциональность проверки можно поместить в абстрактный базовый класс.

Преимущества:
- Вне сборки виден только интерфейс, специфические классы видны только внутри сборки.
- Можно добавлять и изменять классы проверки, не ломая другие сборки в системе.
- Чем меньше открытых типов, тем меньше открытых методов, для которых нужно писать тесты.
- Под открытый API интерфейса можно создавать mock-объекты для тестирования.

Те классы и интерфейсы, которые вы публикуете для внешнего мира, являются вашим контрактом, и вы должны поддерживать его. Чем обширнее этот публичный контракт, тем более ограниченными будут возможности развития. Чем меньше открытых типов, тем больше будет вариантов для изменений и расширения функционала.

Источник: Bill Wagner “More Effective C#”. – 2nd ed. Глава 13.

День пятьсот первый. #MoreEffectiveCSharp
13. Предпочитайте Реализацию Интерфейсов Наследованию
Абстрактные базовые классы предоставляют общего предка для иерархии классов. Интерфейс описывает группу связанных методов, содержащих функционал, который должен быть реализован типом. У каждого подхода своё применение, и они не взаимозаменяемы. Интерфейсы - это способ объявления контракта. Абстрактные базовые классы предоставляют общую абстракцию для набора связанных типов. Наследование означает «является» (описывает, что такое объект), а интерфейс означает «ведёт себя как» (описание одного из поведений объекта).

Особенности интерфейсов:
1. Определяют многократно используемое поведение.
2. Могут быть параметром или возвращаемым значением.
3. Могут быть реализованы несвязанными типами.
4. Другим разработчикам легче реализовать интерфейс, чем наследовать от созданного вами базового класса.
5. Вы не можете обеспечить реализацию методов в интерфейсе. Однако можно создать методы расширения для него. Они будут частью любого типа, который реализует интерфейс.
6. Добавление нового члена к интерфейсу сломает все классы, которые его реализуют. Каждый разработчик должен будет обновить тип, чтобы включить новый член. В C#8 в интерфейсе можно определить реализацию по умолчанию, но этот приём нужно использовать с осторожностью. Если вы обнаружите, что вам нужно добавить функциональность в интерфейс, создайте новый и наследуйте от существующего интерфейса.

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

Интерфейсы как параметры методов
Рассмотрим два метода:

public static void Print<T>(IEnumerable<T> col) {
  foreach (T o in col)
    Console.WriteLine(o);
}
public static void Print(MyCollection col) {
  foreach (var o in col)
    Console.WriteLine(o);
}

Любой тип, который поддерживает IEnumerable<T> (List<T>, SortedList<T>, любой массив и результаты любого запроса LINQ), может использовать первый метод. Второй метод гораздо менее пригоден для повторного использования. Использование интерфейсов в качестве типов параметров метода гораздо более универсально и намного проще для повторного использования.

Интерфейсы как возвращаемые значения
Допустим, ваш класс имеет открытый метод, который возвращает коллекцию объектов:

public List<SomeClass> DataSequence => sequence;
private List<SomeClass> sequence = new List<SomeClass>();

Это создаёт сразу две проблемы:
1. Если вы захотите изменить тип возвращаемого значения со списка на массив или сортированный список, это нарушит код, т.к. это изменит открытый интерфейс вашего класса. Такое изменение заставляет вас делать гораздо больше изменений в системе, чем необходимо: вам нужно будет поменять все места, где происходит обращение к этому методу.
2. Вторая проблема в том, что List<T> предоставляет множество методов для изменения содержащихся в нём данных. Клиенты вашего класса смогут удалять, изменять или даже заменять элементы списка. Почти наверняка вы этого не хотите. К счастью, вы можете ограничить их возможности, вернув вместо ссылки на некоторый внутренний объект интерфейс IEnumerable<SomeClass>. Используя интерфейсы в качестве типа возвращаемого значения, вы можете выбирать, какие методы и свойства для работы с предоставляемыми данными вы хотите открыть для клиентов класса.

Источник: Bill Wagner “More Effective C#”. – 2nd ed. Глава 14.

День пятьсот шестой. #MoreEffectiveCSharp
Новый Паттерн для Логирования Исключений
Логируйте исключения из фильтра исключений, а не из блока catch.
Современные системы логирования поддерживают расширенные контекстные журналы. Вы можете добавлять поля данных в сообщения журнала, а затем использовать их при отладке. Например, отфильтровать журнал по диапазону кодов HTTP или показать только ошибки FileNotFound у пользователя Steve.

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

Большинство методов не логгируют исключения, они выбрасывают их вверх по стеку, где исключение регистрируется на более высоком уровне. Проблема этого подхода заключается в том, что область логгирования теряется после разворачивания стека:
try {
MyMethod();
}
catch (Exception e) {
logger.LogError(e, "");
…
}

Когда генерируется исключение, среда выполнения будет искать в стеке соответствующий обработчик. Cтек разворачивается до найденной точки и выполняется блок catch. Таким образом, дополнительная информация в области логирования, добавленная в методе MyMethod, будет потеряна при логировании исключения из блока catch.

Решение
Фильтры исключений выполняется там, где выбрасывается исключение, а не там, где оно перехватывается. Это происходит до разворачивания стека, поэтому область логирования сохраняется.
Фильтр исключений должен возвращать булево значение, указывающее, подходит ли блок catch под фильтр. В нашем случае логирование - просто побочный эффект, который не влияет на соответствие блока catch фильтру. Определим два метода, возвращающие true или false в зависимости от того, нужно нам «проглотить» исключение, либо выбросить его выше по стеку:

1. Rethrow можно использовать, когда catch не содержит ничего, кроме throw;. В таком случае Rethrow логгирует исключение, вернёт false, блок catch не выполнится, а среда выполнения продолжит искать обработчик выше по стеку:
try {
MyMethod();
}
catch (Exception e) when
(Rethrow(()=>logger.LogError(e, ""))
{
throw;
}
public static bool Rethrow(Action action) {
action();
return false;
}

2. Другой сценарий, когда catch обрабатывает исключение. В этом случае метод Handle логирует исключение, вернёт true, и исключение будет обработано в блоке catch:
try {
MyMethod();
}
catch (Exception e) when
(Handle(()=>logger.LogError(e, ""))
{
// обработка исключения
}
public static bool Handle(Action action) {
action();
return true;
}

Источник: https://blog.stephencleary.com/2020/06/a-new-pattern-for-exception-logging.html

День пятьсот сороковой. #MoreEffectiveCSharp
14. Различайте Интерфейсные и Абстрактные Методы
На первый взгляд реализация интерфейса выглядит так же, как и переопределение абстрактной функции. Но есть различия:
- Реализация абстрактного члена базового класса должна быть виртуальной; реализация члена интерфейса – не обязательно.
- Интерфейсы могут быть реализованы явно, что скроет их реализацию от открытого интерфейса класса.

Рассмотрим варианты реализации простого интерфейса в иерархии классов:

interface IMessage {
  void Message();
}
public class MyClass : IMessage {
  public void Message() => WriteLine(nameof(MyClass));
}

Метод Message() является частью публичного интерфейса MyClass, а также может быть вызван через приведение к IMessage. Теперь добавим производный класс:

public class MyDerivedClass : MyClass {
  public new void Message() =>
    WriteLine(nameof(MyDerivedClass));
}

Нам пришлось добавить ключевое слово new. MyClass.Message() не является виртуальным, его нельзя переопределить. Класс MyDerived создаёт новый метод Message, который не переопределяет MyClass.Message, а скрывает его. Однако MyClass.Message по-прежнему доступен через IMessage:

MyDerivedClass d = new MyDerivedClass();
d.Message(); // выведет "MyDerivedClass"
IMessage m = d as IMessage;
m.Message(); // выведет "MyClass"

Приведение к IMessage вызывает базовую реализацию. Если доступа к базовому классу нет, можно реализовать интерфейс и в производном классе:

public class MyDerivedClass : MyClass, IMessage {…}

Тогда поведение изменится:

m.Message(); // выведет "MyDerivedClass"

Ключевое слово new всё равно придётся использовать. Базовая реализация будет доступна через апкаст:

MyClass b = d;
b.Message(); // выведет "MyClass"

Если доступ к базовому классу есть, объявите интерфейсный метод виртуальным, а в производных классах используйте ключевое слово override. Тогда переопределённая версия метода будет вызываться всегда: и из производного класса, и после приведения как к базовому классу, так и к интерфейсу.

Также можно реализовать интерфейс без фактической реализации его методов:

public abstract class MyClass : IMessage {
  public abstract void Message();
}

Тогда все конкретные производные типы должны переопределить и предоставить собственную реализацию Message(). Интерфейс IMessage является частью объявления MyClass, но реализация методов откладывается до каждого конкретного производного класса.

Можно реализовать паттерн Шаблонный метод:

public class MyClass : IMessage {
  protected virtual void OnMessage() {}
  public void Message() {
    OnMessage();
    WriteLine(nameof(MyClass));
  }
}

Любой производный класс может переопределить OnMessage() и добавить свой код в реализацию контракта IMessage.

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

Источник: Bill Wagner “More Effective C#”. – 2nd ed. Глава 15.

День пятьсот шестьдесят четвёртый. #MoreEffectiveCSharp
16. Реализуйте Паттерн Событий для Уведомлений. Начало
Паттерн событий в .NET - это лишь соглашения о синтаксисе в паттерне Наблюдатель. События определяют уведомления для вашего типа. Они основаны на делегатах, чтобы обеспечить типобезопасные сигнатуры функций для обработчиков событий. События используются, когда ваш тип должен общаться с несколькими клиентами, чтобы информировать их о происходящем в системе.

Например, вы создаёте класс, который действует как диспетчер всех сообщений в приложении. Он принимает все сообщения из источников в вашем приложении и отправляет их всем заинтересованным клиентам. Клиенты могут быть подключены к консоли, базе данных, системному журналу или какому-либо другому механизму:

public class Logger {
  static Logger() {
    Singleton = new Logger();
  }
  private Logger(){}
  public static Logger Singleton { get; }
  // Определяем событие:
  public event EventHandler<LoggerEventArgs> Log;
  // добавляем сообщение
  public void AddMsg(int priority, string msg) =>
    Log?.Invoke(this, new LoggerEventArgs(priority, msg));
}

Метод AddMsg использует оператор ?., который позволяет убедиться, что событие возникает только если на него подписаны наблюдатели.
LoggerEventArgs содержит свойства для приоритета и текста сообщения:

public class LoggerEventArgs : EventArgs {
  public LoggerEventArgs(int priority, string msg) {
    Priority = priority;
    Message = msg;
  }
  public int Priority { get; }
  public string Message { get; }
}

Внутри класса Logger поле event определяет обработчик событий. Компилятор видит определение публичного поля event и создаёт для вас операторы Add (+=) и Remove (-=) для подписки и отписки, которые гарантированно являются потокобезопасными.

Следующий упрощённый класс является примером подписчика. Он подписывается в статическом конструкторе и передаёт делегат, направляющий все сообщения в консоль:

class ConsoleLogger {
  static ConsoleLogger() =>
    Logger.Singleton.Log += (sender, msg) => 
      Console.WriteLine("{0}:\t{1}",
        msg.Priority.ToString(),
        msg.Message);
}

События уведомляют любое количество заинтересованных клиентов о том, что что-то произошло. При этом классу Logger не требуется никаких предварительных знаний о том, какие объекты заинтересованы в регистрации событий.
Пример использования:

var cl = new ConsoleLogger();
Logger.Singleton.AddMsg(1, "test message");

Продолжение следует…

Источник: Bill Wagner “More Effective C#”. – 2nd ed. Глава 15.

День пятьсот шестьдесят пятый. #MoreEffectiveCSharp
16. Реализуйте Паттерн Событий для Уведомлений. Окончание
Начало
Класс Logger содержал только одно событие. Есть классы, которые имеют большое количество событий (у компонентов UI их может быть до сотни). Тогда использовать отдельное поле для каждого события неприемлемо. В приложении фактически используется лишь небольшая часть из них. В этом случае можно создавать объекты событий во время выполнения только при необходимости. Добавим в класс Logger указание подсистемы, отправляющей сообщения. Клиенты будут регистрироваться на сообщения определённой подсистемы. Обновлённый метод AddMsg() теперь принимает строковый параметр, обозначающий подсистему, отправившую сообщение. Кроме того, будет вызываться событие с ключом в виде пустой строки для подписчиков на сообщения от всех подсистем:

public class Logger {
  private static EventHandlerList 
    Handlers = new EventHandlerList();

  static public void AddLogger(string system,
      EventHandler<LoggerEventArgs> ev) =>
    Handlers.AddHandler(system, ev);
  
  static public void RemoveLogger(string system,
      EventHandler<LoggerEventArgs> ev) =>
    Handlers.RemoveHandler(system, ev);
  
  static public void AddMsg(string system, 
      int priority, string msg){
    if (!string.IsNullOrEmpty(system)) {
      EventHandler<LoggerEventArgs> handler =
        Handlers[system] as 
          EventHandler<LoggerEventArgs>;

      LoggerEventArgs args = 
        new LoggerEventArgs(priority, msg);
      handler?.Invoke(null, args);

      // для получателей всех сообщений
      handler = Handlers[""] as 
        EventHandler<LoggerEventArgs>;
      handler?.Invoke(null, args);
    }
  }
}

В этом примере отдельные обработчики событий хранятся в коллекции EventHandlerList. Клиенты подписываются на события подсистемы через AddLogger, передавая ему строковое имя подсистемы и свой делегат обработки сообщения. Первый вызов создаёт событие для подсистемы, последующие вызовы используют это событие. К сожалению, не существует обобщённой версии EventHandlerList, поэтому в AddMsg приходится использовать приведение типов для элементов коллекции.

Вместо EventHandlerList можно использовать словарь Dictionary<string, EventHandler<LoggerEventArgs>>, что добавит немного кода, но позволит использовать строгую типизацию:

…
static public void AddLogger(string system, 
    EventHandler<LoggerEventArgs> ev) {
  if (Handlers.ContainsKey(system))
    Handlers[system] += ev;
  else
    Handlers.Add(system, ev);
}
…
static public void AddMsg(…) {
  if (string.IsNullOrEmpty(system)) {
    EventHandler<LoggerEventArgs> handler = null;
    Handlers.TryGetValue(system, out handler);
    …
  }
}

Источник: Bill Wagner “More Effective C#”. – 2nd ed. Глава 15.

День пятьсот девяносто седьмой. #MoreEffectiveCSharp
17. Избегайте Возврата Ссылок на Внутренний Класс
Вы можете думать, что свойство только для чтения доступно только для чтения и вызывающие объекты не могут его изменять. К сожалению, так получается не всегда. Если свойство возвращает ссылочный тип, вызывающий код может получить доступ к любому общедоступному члену этого объекта, включая те, которые изменяют его состояние. Например:

public class MyObject {
  public MyObject() {
    Data = new List<ImportantData>();
  }
  public List<ImportantData> Data { get; }
  …
}

Получаем доступ к списку и удаляем его элементы. Это поведение не предусмотрено, но и не запрещено:

var stuff = obj.Data;
stuff.Clear();

Таким образом свойство только для чтения - дыра в продуманной инкапсуляции вашего класса. Не говоря уже о том, что создатель класса рассматривает это свойство как неизменяемое и не ожидает подвоха.

Добро пожаловать в чудесный мир ссылочных типов. Любой член, возвращающий ссылочный тип, возвращает указатель на объект. Вы дали вызывающей стороне ссылку на внутренний объект, поэтому ей больше не нужно использовать ваш объект для манипуляции с внутренним объектом.

Очевидно, что вы хотите предотвратить подобное поведение. Вы создали интерфейс для своего класса и хотите, чтобы пользователи использовали его, а не изменяли внутреннее состояние ваших объектов без вашего ведома. Для защиты внутренних данных от непреднамеренных изменений есть 4 стратегии: типы значений, неизменяемые типы, интерфейсы и оболочки.

1. Типы значений копируются, когда клиенты обращаются к ним через свойство. Любые изменения копии, полученной клиентами вашего класса, не влияют на внутреннее состояние вашего объекта.

2. Неизменяемые типы, такие как System.String, также безопасны. Вы можете возвращать строки или любые неизменяемые типы, зная, что ни один клиент вашего класса не сможет их изменить.

3. Интерфейсы позволяют клиентам получать доступ к подмножеству функционала вашего внутреннего члена. Предоставляя функциональность через интерфейс, вы сводите к минимуму вероятность того, что ваши внутренние данные изменятся не так, как вы предполагали. Клиенты могут получить доступ к внутреннему объекту через предоставленный вами интерфейс, который не будет включать в себя все функции класса. В нашем случае публичное свойство можно представлять клиентам в виде IEnumerable<T> вместо List<T>.

4. Последний вариант – предоставить объект-оболочку, минимизирующую варианты доступа к содержащемуся объекту. В .NET представлены различные типы неизменяемых коллекций, которые это поддерживают. Тип System.Collections.ObjectModel.ReadOnlyCollection<T> - это стандартный способ обернуть коллекцию для предоставления во вне данных только для чтения:

public class MyObject {
  private List<ImportantData> listOfData = 
    new List<ImportantData>();

  public ReadOnlyCollection<ImportantData> Data =>
    new ReadOnlyCollection<ImportantData>(listOfData);
  …
}

Итого
Предоставление ссылочных типов через общедоступный интерфейс позволяет пользователям вашего объекта изменять его внутренние компоненты, не используя методы и свойства, которые вы определили. Необходимо изменить интерфейсы вашего класса, чтобы учесть, что вы отдаёте ссылки, а не значения. Ваши клиенты могут вызывать любые методы предоставленных им объектов. Ограничьте доступ, предоставляя внутренние данные с помощью интерфейсов, оболочек или типов значений.

Источник: Bill Wagner “More Effective C#”. – 2nd ed. Глава 17.

День шестьсот девяносто восьмой. #MoreEffectiveCSharp
18. Предпочитайте Переопределения Обработчикам Событий
Многие классы .NET предоставляют два разных способа обработки событий. Вы можете подписать обработчик событий или переопределить виртуальную функцию базового класса. Внутри производных классов вы всегда должны переопределять виртуальную функцию. Ограничьте использование обработчиков событий реагированием на события в несвязанных объектах.

Рассмотрим код приложения WPF, где нужно реагировать на события нажатия мыши. Вы можете переопределить метод OnMouseDown():

public partial class MainWindow : Window
{
  //…
  protected override void OnMouseDown(MouseButtonEventArgs e)
  {
    DoMouseThings(e);
    base.OnMouseDown(e);
  }
}

Либо вы можете подписать обработчик события, что требует изменений как в файле C#, так и в файле XAML:

<Window x:Class="WpfApp1.MainWindow"
  xmlns:local="clr-namespace:WpfApp1"
  mc:Ignorable="d"
  Title="MainWindow" Height="350" Width="525"
  MouseDown="OnMouseDownHandler">
<Grid></Grid>
</Window>

public partial class MainWindow : Window
{
  //…
  private void OnMouseDownHandler(
    object sender, MouseButtonEventArgs e)
  {
    DoMouseThings(e);
  }
}

Следует предпочесть первое решение, и вот почему. При переопределении функции сначала вызывается ваш обработчик, а вызов функции базового класса отвечает за вызов любых обработчиков событий в цепочке. В некоторых редких случаях вам может потребоваться заменить поведение по умолчанию, чтобы другие обработчики не вызывались, но зачастую поведение по умолчанию – то, что вам нужно. Кроме того, в первом варианте нужно поддерживать изменение в одном месте, а во втором – в двух.

Хорошо, но подписка на события зачем-то добавлена. Зачем?
1. Переопределения предназначены для производных классов. Но сторонние классы должны использовать механизм событий.
2. XAML поддерживает декларативную подписку на события. То есть дизайнер приложения в визуальном редакторе может выбрать действие при нажатии мыши, если оно доступно, и не добавлять работы программисту.
3. Это позволяет подписываться на события во время выполнения. Вы можете подключить разные обработчики событий, в зависимости от обстоятельств выполнения программы.
4. Возможно подключить несколько обработчиков к одному событию.

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

Источник: Bill Wagner “More Effective C#”. – 2nd ed. Глава 18.