Разница между ранним и поздним связыванием

В этой публикации я «на пальцах» попытаюсь объяснить, чем отличается раннее и позднее связывание кода для обычного программиста. Не для компилятора или статического анализатора, а для человека, который пишет JavaScript/TypeScript-код.

Для начала пара определений от «Игорь Иваныча» (ИИ), просто в качестве отправной точки:

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

Позднее связывание (late binding) — это процесс, при котором конкретная реализация метода или функции определяется на этапе выполнения программы, а не на этапе компиляции.

Пример

А теперь — по-простому. Вот TypeScript-код, который использует раннее связывание:

class Cat {     speak(): void {         console.log("Meow");     } }  function animalSound(cat: Cat): void {     cat.speak(); }  const myCat = new Cat(); animalSound(myCat);

А это — аналогичный TypeScript-код, который использует позднее связывание:

interface Animal {     speak(): void; }  class Cat implements Animal {     speak(): void {         console.log("Meow");     } }  function animalSound(animal: Animal): void {     animal.speak(); }  const myCat = new Cat();  animalSound(myCat);   

Вот в этом interface Animal и заключается вся разница.

Видно, что кода стало больше, но что нам это дало? А дало возможность декомпозиции нашего кода на составные части:

// animal.ts export interface Animal {     speak(): void; }  export function animalSound(animal: Animal): void {     animal.speak(); }

// cat.ts import {Animal} from './animal';  export class Cat implements Animal {     speak(): void {         console.log("Meow");     } }

// main.ts import {animalSound} from './animal'; import {Cat} from './cat';  const myCat = new Cat(); animalSound(myCat);

У нас получилась такая цепочка зависимостей:

animal.ts => cat.ts => main.ts

Если же мы попытаемся разбить «ранне-связанный» код, то у нас получится немного другая цепочка зависимостей:

cat.ts => animal.ts => main.ts

// cat.ts export class Cat {     speak(): void {         console.log("Meow");     } }

// animal.ts import {Cat} from "./cat";  export function animalSound(animal: Cat): void {     animal.speak(); }

// main.ts import {animalSound} from './animal' import {Cat} from './cat'  const myCat = new Cat(); animalSound(myCat);

Если мы захотим добавить dog в приложение, то animal.ts в коде с ранним связыванием примет вот такой вид:

// animal.ts import {Cat} from "./cat"; import {Dog} from "./dog";  export function animalSound(animal: Cat | Dog): void {     animal.speak(); }

А вот в коде с поздним связыванием animal.ts не изменится.

Вообще.

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

Инверсия Контроля

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

Это несколько контр-интуитивно для тех, кто начинает изучать ООП с «Hello World!» и продолжает двигаться вперёд применяя только инкапсуляцию и наследование. Но как только впервые появляется потребность в полиморфизме, появляется возможность посмотреть на свой код с точки зрения уже позднего связывания.

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

Контейнер Объектов

В случае раннего связывания наш код все зависимости тянет через статические импорты:

import {Cat} from './cat';

Тут всё понятно — и сами разработчики, и куча инструментов (IDE, транспиляторы, анализаторы, …) умеют в статические импорты.

А как же подтягиваются зависимости в случае позднего связывания? Ведь на момент написания кода мы знаем только интерфейсы зависимостей («ходит как утка» и вот этот вот всё)? Кто на момент выполнения кода определяет, какой исходный код, имплементирующий соответствующий интерфейс, должен быть загружен и выполнен, чтобы получить нужную зависимость?

В классическом «кровавом энтерпрайзе» (Java, C#) уже давно ответили на этот вопрос — в приложении должен быть объект, который знает как, когда и какие объекты создавать и когда и куда их внедрять. Обычно его называют «контейнер объектов«.

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

Вместо создания из классов нужных экземпляров по месту их использования:

import {animalSound} from './animal'; import {Cat} from './cat';  const cat = new Cat();  export class CatSound {     makeSound() {         animalSound(cat);     } }

Вы даёте возможность контейнеру объектов предоставить в ваш код нужные зависимости. Например, через конструктор (пример ниже — это уже JavaScript):

export class CatSound {     /**      * @param {Cat} cat      * @param {function(animal: Cat): void} animalSound      */     constructor(cat, animalSound) {         this.makeSound = function () {             animalSound(cat);         };     } }

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

Я в TypeScript не силён, этот код, аналогичный предыдущему, мы писали с «Игорь Иванычем«:

import {Cat} from './cat';  export class CatSound {     constructor(private cat: Cat, private animalSound: (animal: Cat) => void) {     }      public makeSound(): void {         this.animalSound(this.cat);     } }

Так вот, после компиляции в JavaScript статические импорты исчезли, как ненужные:

export class CatSound {     constructor(cat, animalSound) {         this.cat = cat;         this.animalSound = animalSound;     }     makeSound() {         this.animalSound(this.cat);     } }

Что и ожидаемо — ведь наш код ориентирован на позднее связывание, на runtime.

Резюме

На мой взгляд, разницу между типами связывания для программиста, вульгарно, можно свести к следующему:

• раннее: работаем с классами и создаём объекты сами.

• позднее: работаем с контрактами (интерфейсами) и используем готовые объекты, которые предоставляет нам контейнер.

КДПВ как раз демонстрирует идею раннего связывания — вы строите своё приложение из исходников и сами создаёте нужные вам объекты.

Конечно же это очень простое и очень субъективное объяснение. Тем не мнее, возможно, кому-то даст возможность посмотреть на знакомые вещи под незнакомым углом.

Для тех, кто никогда не пробовал позднего связывания, но очень хочет попробовать, вот несколько библиотек, поддерживающих внедрение зависимостей:

• InversifyJS — Мощный DI-контейнер для TypeScript и JavaScript с поддержкой декораторов и аннотаций типов.

• Awilix — Гибкий и лёгкий DI-контейнер для Node.js, оптимизированный для Express и модульных приложений.

• BottleJS — Минималистичный DI-контейнер для JavaScript, поддерживающий фабрики и сервисы.

Ну и по традиции — немного саморекламы. Подписывайтесь на мой телеграм-канал попробуйте мою библиотеку!!

• teqfw/di — DI-контейнер для модульной разработки на JavaScript с минимальной конфигурцией, поддерживающий автозагрузку.

Если будут вопросы по использованию — с интересом отвечу.

Хэппи, как говорится, кодинг…