Events also solve with finality the parameter order problem. There is only ever 1 parameter: The Event. Callbacks, Promises, and Streams can have none, or many. In dynamic languages, you have no compiler help with this. Since most Events are an object of some type, you can add as many slots as you want without changing the interface between sender and receiver. This slightly improves the ability to refactor. In strongly typed languages, the surface API doesn’t change, only the internal consumption which is often opt-in, thus helping keep OOP things OOP. w00t to the w00t. Moot point is moot.
Continue reading “Message Systems in Programming: Part 3 of 7 – Events”
Callbacks are a way be notified of an event and notÂ have to care if it’s synchronous or asynchronous. This could happen immediately or some time later. It’s the “don’t call me, I’ll call you” of programming. It also gives the receiver the power to dictate where they message goes and usually in what scope. In languages that do not natively support blocking, asynchronous programming needs some mechanism to tell you when “things are done”.
Continue reading “Message Systems in Programming: Part 2 of 7 – Callbacks”
Messaging systems are used to communicate in larger code bases by helping decouple classes that need to know about changes or happenings in certain areas of the code. One of Object Oriented Programming‘s core concepts is encapsulation. How you decide to allow objects to talk to each other has pro’s and con’s for each method and it’s good to know your options as you can use many together in effective hybrid approaches.
Continue reading “Message Systems in Programming: Part 1 of 7 – Introduction”