Liam Hegarty – March 12, 2019
Creating objects is one of the cornerstones of Object Oriented Programming and is an essential part of writing Java. Unfortunately instantiating encapsulated units of logic and data is a complex and nuanced problem space, with no one-size-fits-all solution. However, progress is constantly being made in this dynamic, evolving and big-data-enabled field of programming.
Gone are the dark days where we used outdated “builder” design antipatterns to create objects. In these more enlightened, post-parameterisation-from-above times we have found more elegant and straightforward solutions to the dependency injection problem, such as automatically generating reflective bytecode at compile time and inserting it directly into our compiled code.
These dependency injection frameworks make developer life easier by frustrating Quality Assurance and providing job security by reducing readability. Furthermore they tick all the boxes of side-stepping type systems, enabling action at a distance, bypassing interfaces and encapsulating sensitive information about how code works from IDEs and developers alike. How can we hope to improve upon such frameworks? Enter ConstructR.
ConstructR is the Blockchain-powered dependency injection A.I./framework that is changing the way that we write Java. ConstructR allows simple and clean object instantiation in a way that simplifies testing, enables straightforward handling of dependency cycles and expedites development of object management systems. Let us dive straight into how to use ConstructR to create an object.
Object Instantiation
Say we have a simple class called a StringPrinter which needs to print some strings. Unfortunately these Strings need to come from outside of the StringPrinter itself. Now, we all know the industry standard solution would be to bind those strings into a global namespace where they can be accessed by a myriad of different keys. However you should resist this urge to go down the beaten path. Albert Einstein once said “Do not go where the path may lead; go instead where there is no path and leave a trail.” Ironically it was following this advice that cost him his job as a train driver. However, when working with ConstructR it helps to think outside the box. First create a ConstructR helper method with the same name as the class and give arguments for each dependency that are assigned to member variables like so:
private static class StringPrinter {
private final String a;
private final String b;
private final String c;
private final String d;
private final String e;
public StringPrinter(String a, String b, String c, String d, String e) {
this.a = a;
this.b = b;
this.c = c;
this.d = d;
this.e = e;
}
}Now whilst this conflation of object name and ConstructR helper method name may cause confusion, it is a price worth paying for readable instantiation code. The next step is to call this helper method with the help of the helper method helper keyword: new. This ConstructR-specific keyword allows you to create your object in a way that is analogous to calling a method. ConstructR’s cloud-based, big data, blockchain algorithm will leverage the helper method to create a new object. Simply call it like so:
public static void main(String[] args) {
String a = "Making";
String b = "objects";
String c = "isn't";
String d = "that";
String e = "hard";
StringPrinter object = new StringPrinter(a, b, c, d, e);
}This revolutionary method of object “construction” is taking the industry by storm and allows for the injection of any type of dependency. There are some misguided naysayers who maintain that this controversial methodology is too respectful of the basic principles of Object Oriented Programming. However bad programming practice is in fact supported in ConstructR, allowing you to implement bespoke evil logic such as reflection or unchecked type casting.
Supported Notations
Before you ask, yes, ConstructR does support the use of @Tags to create objects. Firstly label the ConstructR call with a tag of your choosing:
@StringPrinter StringPrinter object = new StringPrinter(a, b, c, d, e);
And in order to make it compile, simply comment it out like so:
//@StringPrinter StringPrinter object = new StringPrinter(a, b, c, d, e);
This feature is enabled for ConstructR calls and definitions. It can be used in method bodies and even outside of class bodies. Tag whatever makes you happy with this flexible feature provided by ConstructR. It does come with the downside of not being coloured in that fun yellow colour but this is easily rectified. If using a dark theme simply buy a yellow highlighter from your favourite stationery retailer and then apply it to your screen. If you use a light theme, by this point your eyes are probably too damaged to distinguish between colours and you should book an appointment with your optician immediately.
IDE Integration
Despite ConstructR’s method only having existed for a meagre 20 years or so, where it really beats the competition is in its IDE support. ConstructRs are supported by all popular IDEs, allowing you to see where an object is made with a single click. This also allows you to glean how many instances of an object are made without exhaustively searching your entire codebase for a plethora of invocation formats. Many IDEs even support auto-generation and synergy with the ‘final’ keyword. I am sure many developers out there will be disappointed that this dependency injection framework does not support injecting final members after initialisation, as they are keen to introduce powerful undefined behaviours into their code. Unfortunately this must be done the old fashioned way: via reflection, by making random changes in your bytecode after compilation or simply punching holes in your server racks with a nail gun.
The Future of Object Management Systems
Whilst developers are still getting to grips with experimental features such as direct control over scope, the future of dependency injection is clearly headed in a single direction. ConstructR provides a comprehensive framework which is supported by IDEs, supports multiple notations and actually adheres to the principles of Object Oriented Programming. After quarter of a century of testing this bleeding-edge technology, it is time for Java programmers the world over to ask themselves a question: “Am I ready to make objects in an OOP friendly manner?”