ไม่สามารถเล่นวิดีโอนี้
ขออภัยในความไม่สะดวก

Method Dispatch в Swift (и не только) - Mad Brains Техно 5.07.19

แชร์
ฝัง
  • เผยแพร่เมื่อ 2 ส.ค. 2024
  • Техно - это внутренний еженедельный митап Mad Brains, на котором мы делимся опытом, знакомимся с актуальными технологиями и темами в мобильной разработке и не только.
    Так как мы занимаемся и кроссплатформенной разработкой, и нативной (под обе платформы), на нашем канале выходят видео по разным технологиям. Найти то, что интересно именно тебе. легче всего на странице плейлистов.
    Ссылки и материалы из наших новых видео, полезные статьи в телеграм-канале
    t.me/skills_by_mad
    Вакансии
    bit.ly/MadBrainsWork - HeadHunter
    Мы в соцсетях:
    bit.ly/MadBrainsSite - Сайт
    bit.ly/MadBrainsFB - Facebook
    bit.ly/MadBrainsVK -Вконтакте
    bit.ly/MadBrainsBe - Behance
    bit.ly/MadBrainsInst - instagram

ความคิดเห็น • 17

  • @user-tw6yj2mm4o
    @user-tw6yj2mm4o ปีที่แล้ว +2

    Отличный доклад и интересные дискуссии!

  • @Jeytery
    @Jeytery 2 ปีที่แล้ว +1

    как обычно у мб лучшие доклады на важные темы

  • @user-tw4ut5kl4z
    @user-tw4ut5kl4z 2 ปีที่แล้ว

    Шикарно, лайк

  • @mak_whisk
    @mak_whisk 2 ปีที่แล้ว +1

    Спасибо

  • @nikitababonov9659
    @nikitababonov9659 3 ปีที่แล้ว +9

    final проставляется автоматически в момент компиляции только, если включен флаг whole module optimization, надо было уточнить)

    • @MadBrains
      @MadBrains  3 ปีที่แล้ว +2

      Да, все верно) Не помню уже, почему не упомянул это

    • @Jeytery
      @Jeytery 2 ปีที่แล้ว

      если я правильно понял и для методов класса и для самих классов, от которых никто не наследовался?

  • @ordoko
    @ordoko 5 หลายเดือนก่อน

    Решение о том, какая диспетчеризация использовать для экстеншенов протокола, связано с производительностью и безопасностью типов в Swift. Давайте разберемся подробнее.
    1. **Производительность:**
    - Статическая диспетчеризация обычно более эффективна с точки зрения производительности, чем динамическая диспетчеризация. При статической диспетчеризации компилятор может принять решение о том, какой метод вызывать на этапе компиляции, что позволяет избежать накладных расходов, связанных с поиском методов во время выполнения программы.
    2. **Безопасность типов:**
    - Swift является языком с сильной типизацией, что означает, что компилятор проверяет типы во время компиляции, чтобы предотвратить ошибки во время выполнения. Использование статической диспетчеризации для экстеншенов протоколов помогает поддерживать эту сильную типизацию, поскольку компилятор может гарантировать, что методы, определенные в экстеншене протокола, будут доступны для всех типов, реализующих этот протокол.
    3. **Поддержка расширений в будущем:**
    - Статическая диспетчеризация также облегчает добавление новых методов в протоколы в будущих версиях Swift без необходимости изменения реализации всех типов, реализующих этот протокол. Это связано с тем, что методы, добавленные в протоколы, автоматически становятся доступными для всех типов, реализующих эти протоколы.
    Хотя динамическая диспетчеризация имеет свои преимущества, такие как возможность переопределения методов в подклассах и динамическая загрузка классов во время выполнения, для экстеншенов протоколов статическая диспетчеризация обычно более предпочтительна в контексте Swift из-за упомянутых выше причин.

  • @hahaha9067
    @hahaha9067 3 ปีที่แล้ว

    если я все правильно понимаю, то в табличку на 19:02 можно добавить третий столбец: Initial Declaration AND Extension, в которой будут 3 прочерка (у структур, классов и NSObject такое невозможно), и Table у протоколов. Тогда она станет исчерпывающей)

    • @MadBrains
      @MadBrains  3 ปีที่แล้ว

      Да, идея верная. Но тут скорее взаимное исключение, чем отдельный случай. Если есть определение в протоколе, то будет использоваться Table и в общем-то дальше не важно что в Extension делается

    • @hahaha9067
      @hahaha9067 3 ปีที่แล้ว

      ​@@MadBrains я понял вашу логику, с ней тоже можно согласиться.
      Но вот что интересно: оказывается, компилятор позволяет сделать то же самое (объявить метод в Initial Declaration и Extension одновременно) и для наследников NSObject, тем самым позволяя фактически переопределять методы, не наследуясь, а лишь расширяясь. Что прямо противоречит оф докам по языку свифт. И здравому смыслу, есличес.
      Поэтому я настаиваю на дополнительном столбце:) в нем слишком много интересного и противоречивого

  • @Ko4An1983
    @Ko4An1983 4 ปีที่แล้ว +2

    Отличное видео! А можно ли где-нибудь скачать саму презентацию?

    • @MadBrains
      @MadBrains  4 ปีที่แล้ว +4

      Да, без проблем, в обмен на лайк и репост ;)

    • @antolSergeich
      @antolSergeich 3 ปีที่แล้ว +3

      @George Ymydykov docs.google.com/presentation/d/1uqG-iIpoPPpKr1GeK-R7e9dXnhSYgtiZsk7AqwtYsCQ/edit?usp=sharing

    • @antolSergeich
      @antolSergeich 3 ปีที่แล้ว +1

      docs.google.com/presentation/d/1uqG-iIpoPPpKr1GeK-R7e9dXnhSYgtiZsk7AqwtYsCQ/edit?usp=sharing

    • @vadimorlov4986
      @vadimorlov4986 2 ปีที่แล้ว

      @@MadBrains ребят, помогите плиз разобраться, не могу найти объяснение, почему final func someMethod() {} будет диспатчится статически? ведь мы можем спокойно вызвать override final func viewWillLayoutSubviews() { super.... } и при этом Свифт пойдет в суперы искать первую реализацию.
      То есть если в final классе нет сабклассов или функция override final func, то класс все еще может иметь родителей, а функция может брать поведения super. Разве Свифт не динамически побежит по таблице к суперам?

  • @hashcat5721
    @hashcat5721 ปีที่แล้ว

    20:03 возможно не доступно override так как super.walk вы не вызовите , а без этого нарушение правил Барбары Лисков