Языковые разработчики также являются разработчиками
Это пост, не зависящий от языка. Даже если вы не знаете используемых языков, вы сможете понять его содержание. Я не знаком со всеми используемыми здесь языками, поэтому, если вы обнаружите ошибку в тексте, сообщите мне.
Если вам нравится контент, пожалуйста, помогите распространить информацию, хлопая в ладоши и делясь, и, как всегда, приветствуются критические замечания.
TL;DR;
Поскольку языки программирования сами по себе являются программами, люди, которые их писали, должны были сделать выбор в отношении того, как язык будет развиваться.
Одним из таких решений было то, как программисты будут писать интерфейсы на своих языках. В этой истории рассматриваются различные типы интерфейсов и немного о том, как они влияют на вас.
Программист-компьютерный интерфейс
Люди - рассказчики. В какой-то момент у нас была только наша память, чтобы поддерживать устные традиции, но кто-то начал писать истории на стенах пещер. А потом мы начали писать эти рассказы в тексте.
Развитие - это тоже своего рода повествование. Когда мы пишем код, мы рассказываем, как данные передаются от входа к выходу через серию процедур и решений, используя тот же инструмент, который мы используем, когда пишем сообщение другу: текст.
Текстовые сообщения - это интерфейс программиста к машине.
Определить: интерфейс
Слово интерфейс представляет собой среду, через которую два компонента системы обмениваются информацией.
Когда системы программирования стали реальностью, этот термин был заимствован для обозначения набора данных и / или операций, которые модуль предоставляет как способ использования, но у разработчиков языков были разные идеи о том, как реализовать такие концепцию на свои языки - проблема, с которой разработчики из других областей вообще не сталкиваются 🙃
Мы даже не могли договориться о вызове интерфейсов с одним и тем же именем, например. Протоколы свифта
Разработчики, которые не работают с языками проектирования, часто называют интерфейс контрактом между разработчиком и кодом: мы обязаны реализовать интерфейс в единицу в соответствии с правилами языка, и, в свою очередь, язык позволит этой единице. будет использоваться всякий раз, когда интерфейс подходит.
А поскольку языковые дизайнеры знают, как думают разработчики, они могут принимать некоторые обоснованные решения при написании своих собственных языков. Конечно, язык состоит не только из реализации интерфейса, но эта статья будет посвящена именно этой теме.
Что касается интерфейсов, я (как обычный программист) определил, что появилось 3 разновидности: явность, привязка и номинальность.
Отказ от ответственности: имена (ясность, обязательность и номинальность) пришли мне в голову. Если вы знаете их правильные технические названия, дайте мне знать, чтобы я мог обновить эту историю.
Фактически, я провожу несколько дней в поисках этого похожего на вики-сайта сайта, который я видел несколько лет назад, на котором был похожий пост. Если вы знаете, о чем я говорю, напишите, пожалуйста, ссылку на него.
Явность: есть ли в языке ключевое слово для интерфейсов?
В некоторых языках реализация интерфейса означает использование ключевого слова для создания «типа интерфейса». Не путайте ключевое слово "интерфейс" с типом интерфейса во всем этом сообщении.
Пример ниже на C # показывает эту явность в строке № 4, где вы действительно создаете новый тип интерфейса, который все еще необходимо связать с другими типами (строка № 10) для правильного использования (строки № 38-45). .
Это легкая бюрократия, которая очень выразительно выражает свои намерения. И как побочный эффект, он служит частью вашей проектной документации.
В других языках интерфейсы являются неявными, т. Е. Из-за текстового представления кода язык может разрешить использование модулей, имеющих одинаковые элементы, в одних и тех же ситуациях, имитируя типы интерфейсов, когда это необходимо. Это известно как утиная печать.
Если он ходит как утка и крякает как утка, значит, это должна быть утка.
Можно заметить, что в приведенном ниже Javascript слово «интерфейс» никогда не используется - язык понимает, что Talk означает одно и то же для Cat и Dog. , вам даже не нужно использовать тип интерфейса в качестве посредника.
В то время как раскомментирование строки # 37 C # вызовет семантическую ошибку, Javascript не заботится о нем и, таким образом, более гибок, поскольку программисты теряют четкое представление о том, какие единицы можно использовать для достижения корректности интерфейса, особенно после некоторого рефакторинга.
Конечно, в реальной жизни люди в некоторой степени покрывают вопросы корректности интерфейса написанием тестов в качестве первого клиента своего кода.
Связывание: когда вы узнаете, соответствуют ли ваши устройства своим интерфейсам?
Корректность интерфейса не гарантирует корректности программы. Но если посмотреть, может ли разработчик делегировать эти знания своему языку, это станет одним из аспектов, на которые мы будем обращать внимание.
Связывание - это момент, когда система типов языка узнает о членах типа, связывая имя каждого члена с его реализацией.
Статически типизированные языки заботятся о корректности интерфейса, отказываясь компилировать, когда программисты не могут реализовать интерфейсы в соответствии с правилами языка. Например, раскомментируя строку №37 примера C #, которая покажет вам ошибку во время разработки. Ваши конечные пользователи защищены от этого.
Но для языков с динамической типизацией интерпретатору сложнее заранее знать, в каком направлении будет течь код, когда вы его запустите, а это означает, что некоторые ошибки будут показаны вам только во время выполнения. Ваши конечные пользователи могут не быть защищены.
Выбирая динамический язык вместо статического, вы жертвуете безопасностью за счет большей умственной нагрузки в отношении корректности интерфейса. Это может быть желательно, когда вы хотите писать код быстрее, например, при написании доказательства концепций или прототипа; или научить будущих программистов.
Опять же, TDD может упростить поиск этих ошибок и, таким образом, устранить эти рабочие нагрузки.
Номинальный: нужно ли указывать на языке, что модуль соответствует интерфейсу?
В Javascript, поскольку у длинных единиц есть члены с одинаковыми именами, они могут использоваться как взаимозаменяемые. Но нет никакой гарантии, что эта корректность интерфейса выдержит изменения со временем ни от вас, ни от языка.
В C # это исправлено с помощью ключевого слова для создания типа, но вы должны объявить каждую из единиц, которые могут использоваться взаимозаменяемо.
Третий аспект касается того, может ли язык определить, какие единицы могут использоваться взаимозаменяемо безопасным образом, без необходимости вручную связывать их с интерфейсами.
В Go, если вы объявили интерфейс и ваши модули используют одни и те же имена участников, у вас все в порядке… идти.
До того, как я это увидел, у меня был опыт работы с C # и Node, поэтому мне потребовалось некоторое время, чтобы понять, что происходит в приведенном ниже коде. Когда он наконец пришел, это поразило меня.
Поскольку язык позволяет нам просто беспокоиться об интерфейсах без бюрократии, для меня это похоже на утиную печать на стероидах.
Я не мог придумать плюсы и минусы этого из-за отсутствия опыта в языке, но, похоже, это лучшее из обоих миров: правильность интерфейса и гибкость.
Заключение
Знание, что разные языки имеют очень разные взгляды на лучший способ использования интерфейсов, не поможет вам ни в чем конкретном, но это хорошая вещь, которую нужно знать при выборе следующего языка, который вы хотите выучить, и изящный трюк на собеседовании.
Все дело в компромиссах.
В программировании нет правильного, есть только привкус неправильного.
Лично я чувствовал, что неявные языки всегда будут номинальными, но у меня нет достаточных доказательств, подтверждающих это.
Давайте обсудим, что вы думаете об этой истории, хорошее или плохое, критика всегда приветствуется.
Я хотел бы прочитать несколько комментариев и, если возможно, попросить вас, люди, несколько раз хлопнуть в ладоши и поделиться с друзьями (или врагами, если вы это ненавидите), чтобы распространить информацию.
