OOP try to face up development process by the separation of concerns into different entities. Deconstructing problem domain is a must to organize our code. Also using SRP (Single Responsibility Principle) and IoC (Inversion of Control).
But sometimes OOP is just not enough. Often we’re used to copy and paste code blocks to make things work. Hope you’re agree with me when I say that is ugly and not easy to read.
How many times you were trying to figure out “what does this method really do??” because infrastructure code was scattered across and hiding the real purpose, don’t you?:
Above mentioned. The purpose of that method (::doCheckout) is asign shippingDetails to instance property and then POST it to the server. To achieve this nowadays we’re used to write infrastructure code, for example to validate method params, then make an AJAX request (copy and paste code from other place and change a few variables…) and so on.
If you have to repeat this each time you face this situation you’re not doing your best.
Less code is better than clean code
Of course this is somehow an example, real world problems aren’t easy. We want to achieve this, don’t you? (skip to library)
Not all infrastructure code is CCC, but some do. If we’re pasting the same code changing a few variables or arguments each time to fit the current context. That code is a prime candidate for AOP.
That code can be abstracted and prepared to be injected after or before some method and be able to receive the method/instance context to perform the operation like if it (the code) was here.
This is not magic, just IoC.
In a nutshell, AOP is a toolkit against repetition
If you’re yet not able to understand this article think about console.log placed everywhere, then go cry.
I built this library by trying to implement OOP features in ES5.
For example allowing inheritance without getting your hands dirty in prototypes and overriding parent methods. In the code below I’m declaring Programmer class extending Person class overriding its constructor:
Above example is an implementation of “override” advice which is placed before the method we’re used to override.
When you’re about implement an advice (which is an abstracted code block), you’re used to get method or instance context. meta keyword is the scope metadata, which contains several properties to allow reflection:
AOP is about define and apply patterns/behaviors
Instead of copy and paste blocks of code, with KAOP you can take that code block, making more abstract and then inject it where it is needed.
KAOP enables a way to build your code that allows declarative programming which aims for**:**
Even you’re capable to build Dependency Injection on your own. Because both AOP and DI are reflection techniques:
Previous example consists on Resource class which takes a nodeProvider which if injected into a constructor provides a singleton of node http server instance to each resource subclass and all of them will listen for request having their own resourceIdentifier. So simply we’re giving the responsibility to listen requests per instance and code is well organized and is easy to extend within OOP patterns.
If you liked the article check this example with Angular 2+ app
Done for today, if you care about this topic I highly recommend you to check this.
Any contributions are welcome: