Category: BACK END
A short story from the perspective of a C++ developer
In the beginning…
The year was 1972. Dennis Ritchie, an American computer scientist, created C programming language, the most prominent imperative programming language of today. It was designed to provide constructs that map efficiently to machine instructions. With portability in mind, it was a relief that you can write portable code which can be successfully compiled and run on various computer platforms.
The old world wasn’t sleeping. Almost decade before the first appearance of C, Simula (“Simulation language”) was created at Norwegian Computing Center in Oslo, by Ole-Johan Dahl and Kristen Nygaard. Simula is considered the first object-oriented (OO) programming language.
It will turn out that C and Simula had major influence on today’s most popular programming languages.
In this post I will talk about Dependency Injection with some general examples, what is dependency, what is injection, what happens without it, what happens with it, why do you need it and how to use it on an Android project using Dagger 2.
What is Dependency?
To understand what Dependency Injection is and how it works we first need to understand what are dependencies.
In short, in object oriented programming a dependency is a coupling between two classes of our code, usually because one of them uses the other to do something.
Let’s take a simple example to understand this better:
We have two objects A and B. A needs B to do its job, therefore B is a dependency of an A.
Why Dependencies are bad?
To many dependencies will lead to hard dependency problems which will make our code:
- Hard to reuse
- Hard to test
- Hard to maintain (when project scales up)
Reusability is one of the core commandment of OOP. When classes and methods are coupled and dependant on many things, its reusable nature decreases.
In order to test if our method or class works properly, in most cases, we will need to mock some objects. But if there are so many dependencies within that method or the class it will be hard or impossible to test it.
If a java class creates an instance of another class via the new operator, then it cannot be used and tested independently from that class.
If our code can not be tested properly and the components are not reusable and at the same time the project continues to grow, at some point it will become very difficult to maintain.
Now that we now what dependencies are it’s much easier to explain what Dependency Injection (DI) is.
Dependency Injection is just one of the techniques to avoid dependencies. It is a technique where one object supplies the dependencies of another object. The general concept behind Dependency Injection is called Inversion of Control. According to this concept a class should not configure its dependencies statically but should be configured from the outside. In other words, no class should instantiate another class but should get the instance from a configuration class.
Dagger 2 is one of the open source DI frameworks which generates a lot of boilerplate code for us. It’s the second version of the popular Dagger framework developed by Square inc. Relations between classes in application are represented by Direct Acyclic Graph, hence the name.
Why Dagger 2?
Right now this is the only DI framework which generates fully traceable source code in Java which mimics the code that user may write by hands. It no longer uses reflection, which means it’s more traceable and easy to debug. Also, simplicity and performance of the generated code are on the same level as the hand written code. Long story short, Dagger 2 generates all the dependency injection boilerplate for you.
How dependencies are formed
How does it work?
Dagger 2 works on Annotation processor. So all the code generation is traceable at the compile time.
Annotation processors are code generators that eliminate the boilerplate code by creating code for you during the compile time.
Annotations are the class of metadata, that can be associated with class, methods, fields and even other annotations. Annotations in Java are used to provide additional information, so it is an alternative option for XML and Java marker interfaces. These methods can also be used during the runtime via reflection.
How to use it?
There are 4 main parts in Dagger 2:
- @Inject (base annotation wherby the dependency is requested)
- @Providers (classes which methods provide dependencies)
- @Module (methods inside @Module, which tell Dagger how we want to build and present a dependency)
- @Component (bridge between @Inject and @Module)
First and most important annotation. We can use it for:
- Consturctor injection
- Field injection
- Method injection
Basically , this annotation will tell the Dagger what dependencies need to be transferred to the dependant.
This annotation is used to create the interface which contains methods specifying where you want to perform the injection. In other words, component is a bridge between the generated code and the dependencies.
This annotation declares which objects you want to be available for injection.
For example. We can have a module called DairyModule and this module can provide Milk and Yogurt dependencies to other classes. In this case we need to mark the DairyModule with @Module.
This annotation is used in classes annotated with @Module and is used for methods which provides objects for dependencies injection.
In this article we covered some basic usages of Dagger 2. We already can see some of its strengths and weaknesses, but there is still a lot more to explore. Like @Scope, @Qualifer and how to manage the component. I am sure you have realized how Dagger 2 will change the way we develop our project, especially when combined with MPV pattern and RxJava when it will unleash its full potential.
For me, the best way to understand Dagger 2 is by reading its generated code, in most cases, if you get lost, it will help you to to figure out your problem. Also, I recommend to check the documentation.
Most code starts out as a monolith. This was my experience as well while working on a self-service application for a big telecommunication provider. Idea was to have a separate application where we will expose a lightweight REST API for our modern frontend (Angular 1 at that time). This consumer services application was supposed to be a bridge between CRM and SOAP powered web services and a lightweight client application that we developed using Angular. Without knowing full boundaries of our domain or the extent to which it will grow we started exposing REST services and it seemed like a good approach.
So what is a monolith?
This article assumes some knowledge of Git – basically, if you ever wondered how does Git does the stuff he does, and more importantly, why is all this so complicated.
To understand Git better I propose a simple thought experiment. Let’s imagine that Alice, Bob and Charlie are really dedicated and smart developers, but on one particularly nasty day their Centralized Version Control dies. Now, since all three of them are hardworking, and they still want to deliver their changes to their client, they continue with their work. Later in the day, once all three of them quite a few changes, they need some way to merge all their changes together.
Hello Java enthusiasts and professional developers. If you ever had to face the challenges of one-way server-client communication and are searching for a straightforward solution, you came to the right place. The technology we will go through in this short blog presents an easy and effective solution.
Call it a cliche or anything you like, but when Wikipedia gives you the perfect definition of debugging, trying to come up with your own feels pointless – ‘debugging is the process of finding and resolving defects or problems within the program that prevent correct operation of a computer software or system’.
The term itself was created when a moth got stuck in a relay in a Mark II computer at Harvard University while Admiral Grace Hopper was performing an operation on it in the 1940s.
An actual, real live bug.
When .NET Framework was released 16 years ago, it served as a general application development platform for Windows desktop and Web applications.Shortly after, the .NET Compact Framework was released as a subset of the .NET Framework that fit the footprint of smaller devices, specifically Windows Mobile. The idea behind that was to separate code base from the .NET Framework and it included the entire vertical: a runtime, a framework, and an application model on top. Ever since that, this subsetting was repeated many times with: Silverlight, Windows Phone and Windows Store. This lead to fragmentation because the .NET Platform isn’t a single entity but a set of platforms, owned by different teams, and maintained independently.
Why should we write tests?
Many young and less experienced developers think that writing test is a waste of time, and unnecessary work. But everyone who has experience with a big/long-term project, does not share that opinion. Firstly, with a test you can ensure that your code works as it expected with given inputs, and secondly every later change of your code will be easier and safer, tests will warn developer if developer breaks a functionality.