Система типов — лучший друг программиста

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

Контроль ошибок ввода и обработки - единственный способ уменьшить количество неверных данных до приемлемого уровня!

Пусть у нас будет второй тип с именем VerifiedEmailAddress. Если хотите, он даже может наследовать от EmailAddress

Понимаю, что это всего лишь пример, но тут классическая ловушка наследования. Мало того, что свойство Verified относится скорее к аккаунту, а не к адресу, так еще через пару итераций у нас будет что-то вроде:

• VerifiedEmailAddress

  • VerifiedPersonalEmailAddress

  • VerifiedBusinessEmailAddress

• NonVerifiedEmailAddress

  • NonVerifiedPersonalEmailAddress

  • NonVerifiedBusinessEmailAddress

А потом в эту иерархию понадобиться впихнуть IsActiveEmailAddress, IsSubscribedEmailAddress. Здесь, как мне кажется, более уместна композиция (псевдокод):

class Account:
    email : EmailAddress
    is_verified : bool,
    type : {Personal, Business},
    is_active : bool,
    is_subscribed : bool

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

Sleep(1000) сделает ваш код намного безопаснее в этом плане.

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

"user@server.domain".split("@")[0] // хоть и сложно читается, но просто пишется
"user@server.domain".Domain() // пишется не очевидно, откуда-то большие буквы, домен и поддомен объединены в общем нужно где-то искать доку

Дальше больше поводов для холивара)

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

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

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

• Еще про инкапсуляцию. Со сложными типами невозможно работать без доки. Где-то нужно иметь список всех методов, что они принимают и возвращают. И работа в стиле, пишешь код, альт-таб в браузер, снова в код - это не нян. Порой проще вместо доки использовать исходники. А поглядев на исходники, зачастую возникает желание вообще не использовать эту либу) Да и хорошие доки встречаются редко. В общем все круто, когда сделано идеально, однако в реальности так бывает только когда работают за идею, а сделанным за деньги, пользоваться можно тоже только за деньги.

• Еще про инкапсуляцию. Часто в либах зачем-то используют private и protected, еще конечно константы и прочий сахар, мешающий все поломать. Это конечно прекрасно для разработки либы, однако для публики лучше все делать публичным XD это кажется очень плохой идеей по началу, однако будет меньше людей которые скопировали исходники или применяли хаки, чтобы сделать публичными один два метода, которые им зачем-то все же нужно перегрузить.

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

Дальше уже не столь холиварные рассуждения.

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

• За все нужно платить. Готовый код - менее гибкий, нужно изучать, содержит баги.

• За все нужно платить. Не готовый код - менее универсальный, нужно писать, содержит баги.

• Далеко не везде нужно учитывать разницу в написании количества денег в Германии и Великобритании.

• Очевидных названий методов, классов, констант - не бывает. (Всегда найдутся люди которым не понятно)

• Очевидного поведения, не требующего документации - не бывает.

• Хорошей понятной документации - не бывает.

А теперь рассуждения о том когда все же пора.

1. Если 0.1% ваших пользователей генерируют больше вашей зарплаты, то пора писать код и под них.

2. Если у вас очень много кода, то пора его рефакторить, и запихивать в классы или что там в вашем языке.

3. Если всем в вашей компании привычно, то можно и не то что в языке, но тогда вы привязаны к команде, а команда к компании.

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

5. А если все же услышали, то в вашей компании есть более важные проблемы, чем плохой код.

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

Странный тезис, количество "копеек" в той или иной валюте, весьма опосредованно связано с количеством знаков которые нужно хранить. Например, официальный курс ЦБ (а они-то уж точно знают, сколько копеек в рубле) доллара на сегодня составляет 60,9013 рубля.

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

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

var x = Money.FromMinorUnit(100, "GBP"): £1

var y = Money.FromUnit(100.50, "GBP"): £1.50

Вот прям очень интуитивно же:

var z = Money.FromUnit(150.50, "GBP"): £2.00

var y = Money.FromUnit(100.50, "GBP"): £1.50

Не понял, почему полтора-то?

И в том же прммере, почему x был 1 фунт, а когда стали распечатывать, оказалось полтора?

Понимаю, что перевод, но очень хочется сказать "Раз такой умный, возьми и сделай".

Ещё один замечательный пример — деньги! Просто куча приложений выражает денежные значения при помощи типа decimal. Почему? У этого типа так много проблем, что такое решение мне кажется непостижимым.

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

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

Возможно, для указанных проблем подошла бы не классическая система пользовательских типов на базе ООП, а конструируемая логическая система типов на базе OWL (например).

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

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

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

Отличная статья.

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

float3 color = getColorDocument(…);
color = colorSpace.convertColorDocumentToColorLinear(color);
color = colorSpace.convertColorLinearToColorLAB(color);
color = someColorLABFunction(color);
color = colorSpace.convertColorLinearToColorDocument(color);

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

Все перечисленные проблемы исчезли, как только я сделал следующее:

struct ColorDocument{float3 rgb;};
struct ColorLinear{float3 rgb;};
struct ColorLAB{float3 lab;}

Но появилась новая проблема: как выполнять над структурами математические операции, которые легко делались над примитивными типами?

Поначалу я хотел всё сделать грамотно, в соответствии с системой типов. Например, разность двух объектов ColorLinear порождает объект типа ColorLinearDifference, который цветом уже не является, но его можно прибавить к ColorLinear и получить снова ColorLinear. Закопался на десятки типов и тысячи строк кода. Получилась полная фигня и куча boilerplate-кода.

В итоге выкинул всё, кроме приведённых выше простейших структур, и везде, где нужна математика, напрямую лезу в .rgb или в .lab. Так понятнее, хоть и не полностью «типобезопасно».

Думаю, что лучший друг программиста не на идрисе это все таки дебаггер =) Здорово, конечно, когда на уровне типов можно выразить какие-то полезные свойства программы. Но в каких мейнстрим языках это действительно работает кроме как для небольшого списка задач?

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

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

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

Спасибо, действительно интересно было почитать. Мне порой очень не хватает типа "телефонный номер". После прочтения стал задумываться над созданием такого в каком-нибудь из своих проектов.

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

Замечательные типы - это хорошо, но и сама система типов языка должна предоставлять такую возможность - ADT, pattern matching, желательно HKT или хотя бы GAT's.

С паролем может быть еще хуже, из личного опыта. В проекте которым сейчас занимаюсь случайно получилось так что при восстановлении пароля в базу писался чистый пароль а не его хэш (что, соответственно, означало что A) пользователь не смог-бы войти сменив пароль, и B) было потенциальной уязвимостью), к счастью наш доблестный QA это увидел до выкатки. Как это получилось? Как оказалось, когда все три (инпут с фронта, хэш этого инпута, и хэшированный пароль из базы) все имеют сигнатуру `smthPassword: String` - весьма несложно случайно запихнуть не то значение не в то поле по невнимательности. Решилась проблема использованием тонкой newtype обертки HashedPassword(String), благодаря которой теперь нельзя запихнуть "сырой" пароль String в поле (или функцию) тип которого HashedString, нельзя по-незнанию/наивности сравнить хэш и сырой пароль напрямую, нельзя случайно вывести пароль (точнее его хэш) из микро-сервиса через RPC или записать его в лог, ибо ждя этого типа соответствующие фичи не имплементированы за ненадобностью, etc.

В том что касается первого примера с email - нужно, конечно, подходить к этому без фанатизма, но тем не менее между

//if user.email_verified { // ой, забыл/не знал что такое поле вообще есть
  send_sensitive_data_to(user.email);
//}

и

enum UserEmail {
  NotVerified { email: String },
  Verified { email: String },
}

// send_sensitive_data_to(user.email);
// нельзя, ибо send_sensitive_data_to() ждет строку, а тут какой-то UserEmail

// send_sensitive_data_to(user.email.email);
// нельзя, ибо такое поле есть только у конкретных вариантов а не у всего типа

match user.email {
  NotVerified { email: not_verified_email } => send_sensitive_data_to(not_verified_email);
  //...
}

второй вариант выглядит куда более надежным, так как когда ты не можешь использовать email напрямую (при условии, конечно, что в языке есть средства позволяющие это сделать, как например enum в Rust или closed/sealed типы в Haskell/Scala) и должен руками написать что ты хочешь отправить секретную инфу на конкретно непроверенный email - явно большинство людей заподозрят неладное, даже если они этот проект до этого в глаза не видели и даже не подозревали что есть такая вещь как верификация email.

Плохо как и необъявленная сущность, так и лишняя сущность.

Весь вопрос: как понять, что останется сущностью через месяц хотя бы...

Я согласен с посылом статьи, что типы-обёртки — это классно. Но про VerifiedEmailAddress, который наследует EmailAddress, я вообще не понял. Какого типа будет поле email у класса User-то?

• Если VerifiedEmailAddress, то что если он ещё не Verified?

• Если EmailAddress, то при использовании всё равно нужно

if( email is VerifiedEmailAddress )

что по сути то же самое, что и

if( email.IsVerified() )

• Если два поля, то это вообще жесть, да и всё равно вылезает что-то типа

if( verified_email != null )