The Active Event design pattern, should not be used “instead of” OO, it’s rather a supplement to OO, which enables you to build more robust code and architecture. However, Active Events have a lot of places where they solve conventional problems, far superior to OO. In fact, I’d say that you shouldn’t rely upon any other mechanisms, than the Active Event design pattern, to implement modularity! Meaning, instead of creating old-style interfaces to facilitate for re-use across projects or modules, you should create an Active Event. Imagine you’re creating a Logging component, like the one below.
public class Logging
{
Log(string what);
}
Now all your components, in your system, which needs access to logging, needs to know about the internals of the class “Logging”. All your modules which are going to use the new functionality, need to have the Logging class referenced into their project. You now have a “dependency”. Then Imagine you instead of doing it like the above, you created an Active Event handler for logging, like below.
public class LoggingCore : ActiveController
{
[ActiveEvent(Name = "MyLoggingComponent.Log")]
public static void MyLoggingComponent_Log (object sender, ActiveEventArgs e)
{ ... }
}
This way, the invoker of the active event don’t even need to know about the existence of the other. There would be no needs for any references between the caller and implementer. The method can be changed, or exchanged entirely later by overriding the active event. And the way you’d invoke it would resemble this.
Node node = new Node();
node["what"].Value = "String to log";
RaiseEvent("MyLoggingComponent.Log", node);
And, if you now want to add up another parameter, such as “severity” to your Log method, in the Active Event solution, all you need to do is to check for the parameter inside of your Active Event like this;
if (e.Params.Contains("severity"))
...handle severity parameter ...
This way you could extend your logging functionality, without breaking any previous code, which used “old logging” functionality. This creates far better Modularity than OO, due to that it in its entirety encapsulates the logic of your functionality, behind a transparent haze of Active Events, which can be overridden, interchanged, removed and so on, without having any negative unplanned consequences for the way your system as a whole behaves.
PS!
The way you’d have to add up another parameter like this in traditional OOP, using classes and traditional Polymorphism and Encapsulation mechanisms, would probably resemble something like the code below …
public class Logging
{
Log(string what, string severity);
}
This would break all your existing code, meaning it would need to be recompiled and changed. Alternatively, you could create a new “overload” method, like this …
public class Logging
{
Log(string what);
Log(string what, string severity);
}
However, you’re still battling windmills, since you’ve now made a change to your class, meaning that all DLLs that reference this class, needs to have their reference updated, and probably needs recompiling.
The other alternatives, which is to start inheriting from Logging, creating interfaces, or abstract class factories, et. al., is really so painful, I’d rather not even have to explain it to be honest with you. Fact is; OOP SUCKS!!
With traditional OOP, you cannot easily extend methods or classes, you cannot change the signature of your existing methods without asking for trouble, you can not invoke anything without having a direct reference, being hardwired compiled into your own code, without going through excruciating pains.
All of these problems are solved by the Active Event design pattern, which becomes the entire difference between a modular project, with great capacity for divide and conquer, and such gaining control over your codebase, and a Monolithic Project, built on top of traditional OOP traditions.
This is so, because the Active Event design pattern, makes your Monolithic Applications become composed out of several smaller “components”, which then later sings together, without knowing anything about the specific internals of any other of the “components” in your system. This way, you can mash together existing components, and create new applications out of them, re-configuring using Magix scripting capabilities, and rewiring of Active Events, and such acquire a re-usability of code across projects, dwarfing anything you’ve seen before.
Agility
Needless to say probably, but this also happens to become your very “implementation of Agility” too, since the amount of flexibility and agility you’d end up with, in your end result, would so vastly dwarf anything you’ve experienced earlier, if done correctly, that you’d laugh of how you claimed to be “Agile” in a pre-Active-Events mindset of thinking about Architecture.
Magix facilitates for Agility to such an extent you cannot imagine it, before you’ve started your own Journey …
Meta Capacity
If you take a look at all existing Magix Active Events, you will see that all of them, pretty much, handle a parameter called “inspect”. Meaning, if you invoke any existing Magix Active Event with the parameter “inspect”, you’ll get full description, and some example code back. For dynamically created “functions”, you’ll even get the code that implements the method back.
This way, we can create Meta Capacity for Magix, which enables for automatically running jobs, working on the system as a whole itself, optimizing it, moving things around, rewiring itself, over networks consisting of hundreds of thousands of servers, dancing together as one, even they’re all different, and have different sub-tasks to perform. Not to mention, that this also makes the system as a whole “complete”, in that it’s documentation is an integral part of the system, almost like “literate programming” from Donald Knuth describes.
Unit Testing
The pains of Unit Testing also becomes a breeze, since the Unit Tests themselves are simply active events, starting with the namespace “magix.test.”. Meaning, not only are all Unit Tests an integral part of Magix, and explicitly needs to be removed, if you don’t want them to follow the end project, but these tests can also easily be extended with your own tests. Thanks to the remoting parts of Magix, this even means you can run, maintain and dynamically create new Unit Tests for parts of your server cloud system, combining the Meta Capacity, with the Dynamic Language capabilities together with the Testing Capability of Magix.
In fact, to run the Unit Tests, all you have to do is to invoke the Active Event “magix.tests.run-tests”, and they will automatically run locally on your system.
However, even though O2 is largely an alternative way of thinking about solving some of the things you’ve used OO for so far, it is built itself on top of OO, and you’ll still be using your known classes and such constructs. For instance, you have to inherit from ActiveController to implement a Controller in Magix. These “Monolithic Building Blocks” however, won’t have to be exposed out of the black box, your projects, controllers and components should be.
Magix Facilitates for Exponential Growth in regards to Software Development Productivity …
