Всем доброго нового года!

Навеяно статьей Бизнес, я люблю тебя коллеги Verovir, а также ее же статьей Уходя — уходи? Ночной разговор об увольнениях (хотя последняя заслуживает отдельного развернутого ответа).

Коллега, вы в статье хорошо выделили ключевые проблемные точки, с которыми можно встретиться в ИТ- (и не только) бизнесе.

А вот объективная оценка и рекомендации по каждой этих точек ("что, собственно, произошло, и что делать") — вопрос ой какой дискуссионный.

// Кстати, то же касается и вашей предыдущей статьи

Наверное, почти каждый .NET-разработчик сталкивался со случаями, когда для удобства кодирования рутинных действий и сокращения boilerplate-кода при работе со стандартными типами данных не хватает возможностей стандартной же библиотеки.

И практически в каждом проекте появляются сборки и пространства имен вида Common, ProjectName.Common и т.д., содержащие дополнения для работы со стандартными типами данных: перечислениями Enums, Nullable-структурами, строками и коллекциями — перечислениями IEnumerable<T>, массивами, списками и собственно коллекциями.

Как правило, эти дополнения реализуются с помощью механизма extension methods (методов расширения). Часто можно наблюдать наличие реализаций монад, также построенных на механизме методов расширения.

(Забегая вперед — рассмотрим и вопросы, неожиданно возникающие, и которые можно не заметить, когда созданы свои расширения для IEnumerable<T>, а работа ведется с IQueryable<T>).

Написание этой статьи инспирировано прочтением давней статьи-перевода Проверки на пустые перечисления и развернувшейся дискуссии к ней.

Статья давняя, но тема по-прежнему актуальная, тем более, что код, похожий на пример из статьи, приходилось встречать в реальной работе от проекта к проекту.

В предыдущей публикации мы рассмотрели особенности устройства и работы структур платформы .NET, являющихся "типами по значению" (Value Types) в разрезе сравнения по значению объектов — экземпляров структур.

Теперь рассмотрим готовый пример реализации сравнения по значению объектов — экземпляров структур.

Поможет ли пример для структур более точно определить с предметной (доменной) точки зрения область применимости сравнения объектов по значению в целом, и тем самым упростить образец сравнения по значению объектов — экземпляров классов, являющихся ссылочными типами (Reference Types), выведенный в одной из предыдущих публикаций?

В предыдущей публикации мы вывели наиболее полный и корректный способ реализации сравнения по значению объектов — экземпляров классов (являющихся ссылочными типами — Reference Types) для платформы .NET.

Каким образом нужно модифицировать предложенный способ для корректной реализации сравнения по значению объектов — экземпляров структур (являющихся "типами по значению" — Value Types)?

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

Для предопределенных типов, таких как Boolean или Int32, под сравнением по значению понимается сравнение непосредственно значений экземпляров структур.

Если структура определена разработчиком — пользователем платформы (User defined struct), то сравнение по умолчанию автоматически реализуется как сравнение значений полей экземпляров структур. (Подробности см. в описании метода ValueType.Equals(Object) и операторов == и !=). Также при этом автоматически определенным образом реализуется метод ValueType.GetHashCode(), перекрывающий метод Object.GetHashCode().

И в этом случае есть несколько существенных подводных камней:

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

• перекрытие методов Object.GetHashCode(), Object.Equals(Object);
• реализацию интерфейса IEquatable (Of T);
• реализацию Type-specific статических метода Equals(Person, Person) и операторов ==(Person, Person), !=(Person, Person).

Каждый из способов сравнения для любой одной и той же пары объектов возвращает один и тот же результат:

Person p1 = new Person("John", "Smith", new DateTime(1990, 1, 1));
Person p2 = new Person("John", "Smith", new DateTime(1990, 1, 1));
//Person p2 = new Person("Robert", "Smith", new DateTime(1991, 1, 1));

object o1 = p1;
object o2 = p2;

bool isSamePerson;

isSamePerson = o1.Equals(o2);
isSamePerson = p1.Equals(p2);
isSamePerson = object.Equals(o1, o2);
isSamePerson = Person.Equals(p1, p2);
isSamePerson = p1 == p2;
isSamePerson = !(p1 == p2);

При этом, каждый из способов сравнения является коммутативным:
x.Equals(y) возвращает тот же результат, что и y.Equals(x), и т.д.

Таким образом, клиентский код может сравнивать объекты любым способом — результат сравнения будет детерминирован.

Однако, требует раскрытия вопрос:

Как именно обеспечивается детерминированность результата при реализации статических методов и операторов сравнения в случае наследования — с учетом того, что статические методы и операторы не обладают полиморфным поведением.

Ранее мы рассмотрели корректную реализацию минимально необходимого набора доработок класса для сравнения объектов класса по значению.

Теперь рассмотрим Type-specific реализацию сравнения объектов по значению, включающую реализацию Generic-интерфейса IEquatable(Of T) и перегрузку операторов "==" и "!=".

Type-specific сравнение объектов по значению позволяет достичь:

• Более стабильного, масштабируемого и мнемонического (читаемого) кода (последнее за счет перегруженных операторов).
• Более высокой производительности.

Кроме того, реализация Type-specific сравнения по значению необходима по причинам:

• Стандартные Generic-коллекции (List(Ot T), Dictionary(Of TKey, TValue) и др.) рекомендуют наличие реализации IEquatable(Of T) для всех объектов, помещаемых в коллекции.
• Стандартный компаратор EqualityComparer(Of T).Default использует (по умолчанию — при наличии) реализацию IEquatable(Of T) у операндов.

Реализация одновременно всех способов сравнения сопряжена определенными с трудностями, т.к. для корректной работы требуется обеспечить:

• Соответствие результатов сравнения у различных способов (включая сохранение соответствия при наследовании).
• Минимизацию copy-paste и общего объема кода.
• Учет того, что операторы сравнения технически являются статическими методами и, соответственно, у них отсутствует полиморфность (а также, что не все CLS-совместимые языки поддерживают операторы или их перегрузку).

Рассмотрим Type-specific реализацию сравнения объектов по значению с учетом вышеизложенных условий, на примере класса Person.

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

x.Equals(y) returns the same value as y.Equals(x).

public override bool Equals(object obj)
{
    if ((object)this == obj)
        return true;

    var other = obj as Person;

    if ((object)other == null)
        return false;

    return EqualsHelper(this, other);
}

Общеизвестно, что в объектной модели .NET, как и во многих других программных платформах, сравнивать объекты можно по ссылке и по значению.

Пусть есть класс Person, содержащий персональные данные — имя, фамилию, и дату рождения персоны.

1. минимально необходимый набор доработок класса для того, чтобы объекты этого класса сравнивались по значению с помощью стандартной инфраструктуры .NET;
2. минимально необходимый и достаточный набор доработок, чтобы объекты этого класса всегда сравнивались по значению с помощью стандартной инфраструктуры .NET — если явно не указано, что сравнение должно производиться по ссылке.

В мире объектно-ориентированного программирования уже достаточно давно подвергается критике концепция наследования.

Аргументов достаточно много:

• дочерний класс наследует все данные и поведение родительского, что нужно не всегда (а при доработке родительского в дочерний класс вообще попадают данные и поведение, которые не предполагались на момент разработки дочернего);
• виртуальные методы менее производительные, а в случае, если язык позволяет объявить невиртуальный метод, то как быть, если в наследнике нужно его перекрыть (можно пометить метод словом new, но при этом не будет работать полиморфизм, и использование такого объекта может привести к неожидаемому поведению, в зависимости от того, к какому типу приведен объект в момент его использования);
• если возникает необходимость множественного наследования, то в большинстве языков оно отсутствует, а там, где есть (C++), считается трудоемким;
• есть задачи, где наследование как таковое не может помочь — если нужен контейнер элементов (множество, массив, список) с единым поведением для элементов разных типов, и при этом нужно обеспечить статическую типизацию, то здесь помогут обобщения (generics).
• и т.д., и т.п.

Unsafe Mode
01: b1        : True
02: b2        : True
03:  b1 ==  b2: False
04: !b1 == !b2: True
05: b1 && b2  : True
06: b1 &  b2  : True
07: b1 ^  b2  : True
08: b1 && b3  : True
09: b1 &  b3  : False
10: b1 ^  b3  : True

Safe Mode
11: b1        : True
12: b2        : True
13:  b1 ==  b2: True
14: !b1 == !b2: True
15: b1 && b2  : True
16: b1 &  b2  : True
17: b1 ^  b2  : False
18: b1 && b3  : True
19: b1 &  b3  : True
20: b1 ^  b3  : False

1. Почему в блоках Unsafe и Safe Mode разные результат в позициях 03 и 13, 07 и 17, 09 и 19, 10 и 20 соответственно?
   (а почему тогда значения в других соответствующих друг другу позициях в блоках Unsafe и Safe совпадают?)
2. Почему внутри блока Unsafe результаты в позициях 05 и 06 одинаковы, а в 08 и 09 — разные?
   И почему результаты в 08 и 09 разные?

Рассмотрим принципы современной организации процесса разработки, в большей степени присущие современным гибким (Agile) методологиям, чем «водопаду» (Waterfall).

1. Аналитики создают модель предметной области в своих терминах, разработчики программируют ее в своих (в той или иной парадигме программирования).
Нужно, чтобы кто-то «наводил мосты» между первыми и вторыми.

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

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

• класс/таблицу вида «Машины» (здесь и далее класс употребляю в терминах ООП);
• класс/таблицу вида «Список машин»;
• класс/таблицу вида «Машина».

А далее следуют ожидаемые проблемы:

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