Мультиметод

Разработчики программ, как правило, группируют исходный код в именованные блоки, называемые вызовами, процедурами, подпрограммами, функциями или методами. Код функции выполняется путём её вызова, который заключается в выполнении фрагмента кода, обозначенного её именем. При этом управление временно передаётся вызываемой функции; когда выполнение этой функции завершается, управление обычно передаётся обратно команде, следующей после вызова функции.

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

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

special.method (other, arguments, here) 

так что lion.sound() будет давать рев, а sparrow.sound() будет давать чириканье.

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

Common Lisp Object System (CLOS) является одной из первых и хорошо известных реализаций множественной диспетчеризации.

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

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

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

Для того чтобы оценить, насколько часто множественная диспетчеризация используется на практике, Мушевичи (Muschevici) с соавторами[1] исследовал приложения, использующие динамическую диспетчеризацию. Они проанализировали девять приложений, в основном компиляторов, написанных на шести различных языках программирования: Common Lisp Object System, Dylan, Cecil, MultiJava, Diesel и Nice. Результаты показывают, что от 13% до 32% обобщенных функций используют динамическую типизацию одного аргумента, в то время как от 2,7% до 6,5% функций используют динамическую типизацию нескольких аргументов. Остальные 65%-93% обобщенных функций имеют один конкретный метод (перегружены), и, таким образом, не рассматривались как использующие динамическую типизацию своих аргументов. Кроме того, в исследовании сообщается, что от 2% до 20% обобщенных функций имели две, а 3%-6% имели три свои конкретные реализации. Доля функций с большим числом конкретных реализаций быстро уменьшалась.

Теория языков с мультивызовами впервые была разработана Кастаньей (Castagna) с соавторами, путём определения модели для перегруженных функций с поздним связыванием[2][3]. Это дало первую формализацию проблемы ковариации и контрвариации объектно ориентированных языков программирования[4] и решение проблемы бинарных методов[5].

Для лучшего понимания разницы между мультиметодами и одиночной диспетчеризацией можно продемонстрировать следующий пример. Представим себе игру, в которой, наряду с разнообразными другими объектами, присутствуют астероиды и космические корабли. Когда два каких-либо объекта сталкиваются, программа должна выбрать какой-либо определенный алгоритм действий, в зависимости от того, что столкнулось с чем.

(defgeneric collide (x y))

(defmethod collide ((x asteroid) (y asteroid))
  ;;астероид сталкивается с астероидом
  )

(defmethod collide ((x asteroid) (y spaceship))
  ;;астероид сталкивается с космическим кораблем
  )

(defmethod collide ((x spaceship) (y asteroid))
  ;;космический корабль сталкивается с астероидом
  )

(defmethod collide ((x spaceship) (y spaceship))
  ;;космический корабль сталкивается с космическим кораблем
  )

subset Mass of Real where 0 ^..^ Inf; 
role Stellar-Object {
  has Mass $.mass is required;
  method name () returns Str {...};
}
class Asteroid does Stellar-Object {
  method name () { 'an asteroid' }
}
class Spaceship does Stellar-Object {
  has Str $.name = 'some unnamed spaceship';
}
my Str @destroyed = < obliterated destroyed mangled >;
my Str @damaged = « damaged 'collided with' 'was damaged by' »;

# We add multi candidates to the numeric comparison operators because we are comparing them numerically,
# but doesn't make sense to have the objects coerce to a Numeric type.
# ( If they did coerce we wouldn't necessarily need to add these operators. )
# We could have also defined entirely new operators this same way.
multi sub infix:« <=> » ( Stellar-Object:D $a, Stellar-Object:D $b ) { $a.mass <=> $b.mass }
multi sub infix:« <   » ( Stellar-Object:D $a, Stellar-Object:D $b ) { $a.mass <   $b.mass }
multi sub infix:«   > » ( Stellar-Object:D $a, Stellar-Object:D $b ) { $a.mass   > $b.mass }
multi sub infix:«  == » ( Stellar-Object:D $a, Stellar-Object:D $b ) { $a.mass  == $b.mass }

# Define a new multi dispatcher, and add some type constraints to the parameters.
# If we didn't define it we would have gotten a generic one that didn't have constraints.
proto sub collide ( Stellar-Object:D $, Stellar-Object:D $ ) {*}

# No need to repeat the types here since they are the same as the prototype.
# The 'where' constraint technically only applies to $b not the whole signature.
# Note that the 'where' constraint uses the `<` operator candidate we added earlier.
multi sub collide ( $a, $b where $a < $b ) {
  say "$a.name() was @destroyed.pick() by $b.name()";
}
multi sub collide ( $a, $b where $a > $b ) {
  # redispatch to the previous candidate with the arguments swapped
  samewith $b, $a;
}

# This has to be after the first two because the other ones
# have 'where' constraints, which get checked in the
# order the subs were written. ( This one would always match. )
multi sub collide ( $a, $b ){
  # randomize the order
  my ($n1,$n2) = ( $a.name, $b.name ).pick(*);
  say "$n1 @damaged.pick() $n2";
}

# The following two candidates can be anywhere after the proto,
# because they have more specialized types than the preceding three.

# If the ships have unequal mass one of the first two candidates gets called instead.
multi sub collide ( Spaceship $a, Spaceship $b where $a == $b ){
  my ($n1,$n2) = ( $a.name, $b.name ).pick(*);
  say "$n1 collided with $n2, and both ships were ",
  ( @destroyed.pick, 'left damaged' ).pick;
}

# You can unpack the attributes into variables within the signature.
# You could even have a constraint on them `(:mass($a) where 10)`.
multi sub collide ( Asteroid $ (:mass($a)), Asteroid $ (:mass($b)) ){
  say "two asteroids collided and combined into one larger asteroid of mass { $a + $b }";
}

my Spaceship $Enterprise .= new(:mass(1),:name('The Enterprise'));
collide Asteroid.new(:mass(.1)), $Enterprise;
collide $Enterprise, Spaceship.new(:mass(.1));
collide $Enterprise, Asteroid.new(:mass(1));
collide $Enterprise, Spaceship.new(:mass(1));
collide Asteroid.new(:mass(10)), Asteroid.new(:mass(5));

from multimethods import Dispatch
from game_objects import Asteroid, Spaceship
from game_behaviors import ASFunc, SSFunc, SAFunc
collide = Dispatch()
collide.add_rule((Asteroid,  Spaceship), ASFunc)
collide.add_rule((Spaceship, Spaceship), SSFunc)
collide.add_rule((Spaceship,  Asteroid), SAFunc)
def AAFunc(a, b):
    """Behavior when asteroid hits asteroid"""
    # ...define new behavior...
collide.add_rule((Asteroid, Asteroid), AAFunc)

# ...later...
collide(thing1, thing2)

@multimethod(Asteroid, Asteroid)
def collide(a, b):
    """Behavior when asteroid hits asteroid"""
    # ...define new behavior...
@multimethod(Asteroid, Spaceship)
def collide(a, b):
    """Behavior when asteroid hits spaceship"""
    # ...define new behavior...
# ... define other multimethod rules ...

• Common Lisp (посредством Common Lisp Object System)[12]
• Haskell, посредством мультипараметрических классов типов[13]
• Scala, также посредством мультипараметрических классов типов
• Elixir[14]
• Dylan[15]
• Nice[16]
• Cecil[17]
• R[18]
• Julia[19] 
• Groovy[20]
• Lasso[21]
• Raku[22]
• Seed7[23]
• Clojure[24]
• C# 4.0[25]
• Fortress[26]
• TADS[27]
• Xtend[28]
• Nim[29]

Поддержка мультиметодов в других языках путём расширений:

• Scheme (посредством TinyCLOS)
• Python (посредством PEAK-Rules, RuleDispatch, gnosis.magic.multimethods, PyMultimethods, или multipledispatch)
• Perl (посредством модуля Class::Multimethods)
• Java (посредством расширения MultiJava)
• Ruby (посредством библиотеки The Multiple Dispatch Library, пакетов Multimethod и Vlx-Multimethods)
• .NET (посредством библиотекиy MultiMethods.NET)
• C# (посредством библиотеки multimethod-sharp)
• C++ (посредством библиотеки yomm11)
• Factor (в стандарте multi-methods vocabulary)

Мультипараметрические классы типов в Haskell и Scala также могут быть использованы для эмуляции мультиметодов.