The goal of scheduling is to dynamically decide what to do in your function.
If you have a (dynamic) dispatch function main (or only if you do not need casting or other transformations), then the responsibility is to decide which other function to call. This decision is often based on the type of instance on which the method is called, or on the type of some parameters, but may also depend, for example, on the value of the parameter (s) or some configuration values.
A scheduling rule can be hard-coded (for example, using pattern matching in scala) or can be obtained from a scheduling table.
As you mentioned, there are several options, such as a separate dispatch (the specific method depends on the instance on which the original method is called, which is the main OO mechanism), double dispatch (sends a function call to various specific functions depending on the execution time of several objects participating in the call).
A related design pattern is Visitor, which allows you to dynamically add a set of functions to existing classes and which also has a dynamic dispatch across its core.
Nested blocks / closures appear when you define a specific method inside the send method or in some initialization code (for example, for a distribution table).
A simple example for the case when scheduling is based on a parameter value, with a hard-coded solution and with a scheduling table:
class Dispatch { def helloJohn(): String = "Hello John" def helloJoe(): String = "Hello Joe" def helloOthers(): String = "Hello" def sayHello(msg: String): String = msg match { case "John" => helloJohn() case "Joe" => helloJoe() case _ => helloOthers() } val fs = Map("John" -> helloJohn _, "Joe" -> helloJoe _) def sayHelloDispatchTable(msg: String): String = fs.get(msg) match { case Some(f) => f() case _ => helloOthers() } }
Sandor murakozi
source share