Заблуждение первое: аналитик путает высказывание в логике высказываний с высказыванием в логике предикатов

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

Первая ошибка связана с тем, что аналитики не умеют разделять эти высказывания. Допустим, что аналитик нарисовал диаграмму в нотации BPMN: два квадратика, связанных друг с другом стрелкой. Первый квадратик он назвал "закрепить заготовку в станке", второй квадратик он назвал: "выточить деталь". При этом аналитик сказал: после операции "закрепить заготовку в станке" следует операция "выточить деталь". Что он имел ввиду? Он имел ввиду, что после операции типа "закрепить заготовку в станке" следует операция типа "выточить деталь". То есть, он построил высказывание в предикатах первого порядка. Однако, аналитик путает простые высказывания с высказываниями в логике предикатов и думает, что он сделал простое высказывание.

Следствие из первого заблуждения: в ИТ отрасли появился костыль, прикрывающий эту ошибку. Этот костыль — слово экземпляр. Когда вы слышите слово "экземпляр чего-то" из уст аналитика, знайте, он — путает простые высказывания с высказываниями в логике предикатов.

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

Первые два года

Введение

В предыдущей публикации мы получили вариант реализации сравнения объектов по значению для платформы .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).
• и т.д., и т.п.

• Общая часть
  • Список терминов и определений
  • Описание бизнес-ролей
  
• Требования
  • Бизнес-требования
  
  • Общие сценарии
  • Сценарии использования
  • Алгоритмы и проверки
  • Системные требования
  • Нефункциональные требования
  • Требования к интеграции
  • Требования к пользовательскому интерфейсу
• Реализация
• Тестирование
• Руководства
• Управление

• FT, DTF, DTFT — в чем отличия и как совершенно разные казалось бы формулы дают столь концептуально похожие результаты?
• Как правильно интерпретировать результаты быстрого преобразования Фурье (FFT)
• Что делать если дан сигнал из 179 сэмплов а БПФ требует на вход последовательность по длине равную степени двойки
• Почему при попытке получить с помощью Фурье спектр синусоиды вместо ожидаемой одиночной “палки” на графике вылезает странная загогулина и что с этим можно сделать
• Зачем перед АЦП и после ЦАП ставят аналоговые фильтры
• Можно ли оцифровать АЦП сигнал с частотой выше половины частоты дискретизации (школьный ответ неверен, правильный ответ — можно)
• Как по цифровой последовательности восстанавливают исходный сигнал