Aspect Oriented Programming in Javascript (ES5+\Typescript)

Javascript world evolved very fast in the last 8 years. But we’re stuck in some problems that I’ll try to explain in this article and provide a solution.

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)


Introducing AOP

Aspect Oriented Programming is about smash CCC (Cross-cutting concerns).

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.


Featuring KAOP/KAOP-TS

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:

Modern versions of Javascript do this. But when I succeeded got realized that “override” is just a code block injected before a method execution which takes the context of the annotated method to do some stuff… which is an interesting technique that remind me to AOP Alliance or Spring in Java.

basically apply just executes super call with invoked arguments while implement actually injects super method

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:

both kaop and its TypeScript version kaop-ts have the same API to access scope context
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:

“Remove side effects by describing what the program must accomplish in terms of the problem domain, rather than describe how to accomplish it as a sequence of the programming language primitives”.

Even you’re capable to build Dependency Injection on your own. Because both AOP and DI are reflection techniques:

simplified from https://github.com/k1r0s/ritley/blob/master/lib/abstract-resource.js

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:

Hacker Noon is how hackers start their afternoons. We’re a part of the @AMIfamily. We are now accepting submissions and happy to discuss advertising & sponsorship opportunities.
To learn more, read our about page, like/message us on Facebook, or simply, tweet/DM @HackerNoon.
If you enjoyed this story, we recommend reading our latest tech stories and trending tech stories. Until next time, don’t take the realities of the world for granted!