This post is part of a multiple parts tutorial, This part, as the heading suggests will focus on leveraging Dependency Injection with Google Guice.
It's advised to start with Part 1 - Merely a design pattern, to have a sufficient understanding of the dependency injection design pattern required for this part of the tutorial.
But, in you wanna start here instead, I'll recap in a sentence: Dependency Injection is merely a design pattern, a technique, for achieving Inversion of Control by writing loosely-coupled code.
That's it, you're all caught up. 😁
The next part of this tutorial is quite similar to this one using a different di framework: Part 3 - Leveraging with Spring Context. You can opt to read it instead of this one, in case you prefer Spring.
If you're still here, let's dive in...
So... You're probably asking yourselves, what is there to leverage in a base code that follows the dependency injection design pattern ❔
The answer is simple, Everything... ❕
I promise you, by the time you'll get through this post, you'll understand the benefits and the necessity of incorporating a di framework in your app.
First, let's touch base about how does dependency injection frameworks work... It's pretty straight forward, the framework creates dependencies for you!
On one end, you give the framework specific instructions on how to create your dependencies, on the other end, your objects can either declare the dependencies they need or ask the framework directly for them. Either way, the framework will comply and return the dependencies as you instructed it.
That's di frameworks in a nutshell, every DI framework, and I mean Every DI Framework, I came across, basically works the same.
Sure, there may be different features, different component names, different default behaviors, and most probably different implementation under the hood.
But, to us, the users of those frameworks, there are so many similarities, that I can safely say, If you know one well enough, catching up to another one, should be a piece of 🍰.
For instance, you can find similarities between:
Spring's Autowired and Guice's Inject, both mark a dependency for injection.
Spring's Bean and Guice's Provides, both incorporate logic for creating a dependency.
Not a believer yet ❔ Alright, let's throw C# in the mix ❕
Spring's Configuration, Guice's Modules, and Autofac's Modules, can be used to configure dependencies.
Guice's Binding and Autofac's Registration, are used to configure dependencies with the framework's DSL.
I can go on... But I believe my point is made. 😎
Under the hood, the framework builds factories that can provide the dependencies to objects based on multiple criteria, such as type and name.
At the base level, there are three common lifecycle scopes for dependencies living in the di framework context:
Eager Singleton: one instance of the dependency will be created in the framework's context immediately upon the framework's instantiation, the same instance will be used by any objects living in the context.
Lazy Singleton: one instance of the dependency will be created in the framework's context only after the dependency is declared by an object, upon its instantiation, the same instance will be used by any objects living in the context.
Non-Singleton: an instance of the dependency will be created per declaration upon every declaration, meaning, every object declaring will get his instance of the dependency.
There are more scopes, but these are the most commonly used three. You'll probably bump into dependencies per-session, per-request, per-dependency, and so on... Some frameworks offer different scopes than others, as features.
So... Let's code.
Heads up, the example application is the same as the one in Part 1 - Merely a design pattern minus the parts before incorporating the dependency injection design pattern. If you got the app section from Part 1, you can skip to the incorporating guice section.
You can check out the code for this part of the tutorial in Github.
Let's build an app that collects mail from both Gmail and Microsoft leveraging the Dependency Injection pattern with Google Guice.
An Enum called MailSource for categorizing the mail source:
public enum MailSource {
GMAIL,
MICROSOFT;
}An abstract class Mail for contracting mail objects.
public abstract class Mail {
public abstract String from();
public abstract String subject();
public abstract MailSource source();
@Override
public String toString() {
return String.format("Got mail by %s, from %s, with the subject %s", source(), from(), subject());
}
}An interface for contracting services responsible for collecting mail from suppliers, the MailService.
public interface MailService {
List<Mail> getMail();
}And last, an interface for contracting an engine responsible for collecting mail from multiple services, the MailEngine.
public interface MailEngine {
List<Mail> getAllMail();
}For convinience and immutability, The concrete Mail implementaions were designed with a builder pattern.
The Gmail Mail implementation, GmailImpl:
public final class GmailImpl extends Mail {
private final String setFrom;
private final String setSubject;
private GmailImpl(final String from, final String subject) {
setFrom = from;
setSubject = subject;
}
@Override
public String from() {
return setFrom;
}
@Override
public String subject() {
return setSubject;
}
@Override
public MailSource source() {
return MailSource.GMAIL;
}
public static GmailImpl.Builder builder() {
return new GmailImpl.Builder();
}
public static final class Builder {
private String prepFrom;
private String prepSubject;
public Builder from(final String setFrom) {
prepFrom = setFrom;
return this;
}
public Builder subject(final String setSubject) {
prepSubject = setSubject;
return this;
}
public GmailImpl build() {
requireNonNull(emptyToNull(prepFrom), "from cannot be empty or null");
requireNonNull(emptyToNull(prepSubject), "subject cannot be empty or null");
return new GmailImpl(prepFrom, prepSubject);
}
}
}The Micsorosft Mail implementation, MicrosoftImpl:
public final class MicrosoftImpl extends Mail {
private final String setFrom;
private final String setSubject;
private MicrosoftImpl(final String from, final String subject) {
setFrom = from;
setSubject = subject;
}
@Override
public String from() {
return setFrom;
}
@Override
public String subject() {
return setSubject;
}
@Override
public MailSource source() {
return MailSource.MICROSOFT;
}
public static MicrosoftImpl.Builder builder() {
return new MicrosoftImpl.Builder();
}
public static final class Builder {
private String prepFrom;
private String prepSubject;
public Builder from(final String setFrom) {
prepFrom = setFrom;
return this;
}
public Builder subject(final String setSubject) {
prepSubject = setSubject;
return this;
}
public MicrosoftImpl build() {
requireNonNull(emptyToNull(prepFrom), "from cannot be empty or null");
requireNonNull(emptyToNull(prepSubject), "subject cannot be empty or null");
return new MicrosoftImpl(prepFrom, prepSubject);
}
}
}The Gmail MailService implementation:
public final class GmailService implements MailService {
@Override
public List<Mail> getMail() {
// this is where the actual Gmail api access goes.
// we'll fake a couple of mails instead.
var firstFakeMail =
GmailImpl.builder()
.from("a.cool.friend@gmail.com")
.subject("wanna get together and write some code?")
.build();
var secondFakeMail =
GmailImpl.builder()
.from("an.annoying.salesman@some.company.com")
.subject("wanna buy some stuff?")
.build();
return List.of(firstFakeMail, secondFakeMail);
}
}The Microsoft MailService implementation:
public final class MicrosoftService implements MailService {
@Override
public List<Mail> getMail() {
// this is where the actual Microsoft api access goes.
// we'll fake a couple of mails instead.
var firstFakeMail =
MicrosoftImpl.builder()
.from("my.boss@work.info")
.subject("stop writing tutorials and get back to work!")
.build();
var secondFakeMail =
MicrosoftImpl.builder()
.from("next.door.neighbor@kibutz.org")
.subject("do you have philips screwdriver?")
.build();
return List.of(firstFakeMail, secondFakeMail);
}
}The concrete implementation of MailEngine is RobustMailEngine, it collects the mail from the different services:
public final class RobustMailEngine implements MailEngine {
private final Set<MailService> mailServices;
public RobustMailEngine(final Set<MailService> setMailSerices) {
mailServices = setMailSerices;
}
@Override
public List<Mail> getAllMail() {
return mailServices.stream().map(MailService::getMail).flatMap(List::stream).collect(toList());
}
}This is the app itself, the MailCollectorApp:
public final class MailCollectorApp {
private MailEngine engine;
public MailCollectorApp(final MailEngine setEngine) {
engine = setEngine;
}
public String getMail() {
var ret = "No mail found.";
if (!engine.getAllMail().isEmpty()) {
ret = Joiner.on(System.lineSeparator()).join(engine.getAllMail());
}
return ret;
}
public static void main(final String... args) {
var gmailService = new GmailService();
var microsoftService = new MicrosoftService();
var engine = new RobustMailEngine(Set.of(gmailService, microsoftService));
var app = new MailCollectorApp(engine);
System.out.println(app.getMail());
}
}Executing the main method will print:
Got mail by GMAIL, from a.cool.friend@gmail.com, with the subject wanna get together and write some code?
Got mail by GMAIL, from an.annoying.salesman@some.company.com, with the subject wanna buy some stuff?
Got mail by MICROSOFT, from my.boss@work.info, with the subject stop writing tutorials and get back to work!
Got mail by MICROSOFT, from next.door.neighbor@kibutz.org, with the subject do you have a star screwdriver?As you may have noticed, this application designed with the dependency injection design pattern in mind.
The dependencies are currently controlled by the main method, so it should be easy to incorporate Google Guice.
First off, add this to your pom.xml in the dependencies section: Please note the version, this version was the latest at the time this tutorial was written.
<dependency>
<groupId>com.google.inject</groupId>
<artifactId>guice</artifactId>
<version>4.2.3</version>
</dependency>We need to tell Guice about the dependencies we want to be injected. Let's do this for the concrete engine class:
public final class RobustMailEngine implements MailEngine {
private final Set<MailService> mailServices;
@Inject
public RobustMailEngine(final Set<MailService> setMailSerices) {
mailServices = setMailSerices;
}
@Override
public List<Mail> getAllMail() {
return mailServices.stream().map(MailService::getMail).flatMap(List::stream).collect(toList());
}
}And for the app class:
public final class MailCollectorApp {
private MailEngine engine;
@Inject
public MailCollectorApp(final MailEngine setEngine) {
engine = setEngine;
}
public String getMail() {
var ret = "No mail found.";
if (!engine.getAllMail().isEmpty()) {
ret = Joiner.on(System.lineSeparator()).join(engine.getAllMail());
}
return ret;
}
//...
}All we did by adding @Inject annotation on both classes constructor, is tell Guice we need it to provide the dependencies in those constructors for us.
Now, we need to instruct Guice on how to provide those dependencies.
Let's create a Guice Module for configuring the bindings, there are a couple of ways for achiving that. For instance, using Guice's Provides Methods:
public final class DIModule extends AbstractModule {
@Provides
static Set<MailService> getServices() {
return Set.of(new GmailService(), new MicrosoftService());
}
@Provides
@Singleton
static MailEngine getEngine(final Set<MailService> services) {
return new RobustMailEngine(services);
}
}Another option is using Guice's bind DSL:
public final class DIModule extends AbstractModule {
@Override
public void configure() {
var listBinder = newSetBinder(binder(), MailService.class);
listBinder.addBinding().toInstance(new GmailService());
listBinder.addBinding().toInstance(new MicrosoftService());
bind(MailEngine.class).to(RobustMailEngine.class).in(Scopes.SINGLETON);
}
}Both options will produce the same dependencies. From a Scopes point-of-view... Guice's default scope is Non-Singleton, meaning the Set of GmailService and MicrosoftService will be created as new instances for every object who needs them.
The RobustMailEngine on the other end is bound as a Singelton. Based on Guice's docs, that means that in Production stage it will be an Eager Singleton, and in Development stage it will be a Lazy Singleton. Either way, it's going to be a Singleton, meaning our app will have only one instance of RobustMailEngine.
The default stage for Guice is Development stage, so we can expect a Lazy Singleton.
Please note, RobustMailEngine is a dependency, it will be injected to whoever needs it, but as we configured earlier with @Inject, it also needs dependencies for itself (the Set of MailService). Guice will catch that and inject the set of mail services while instantiating the engine.
Let's get back to the to our app and update it to work with Guice:
public final class MailCollectorApp {
private MailEngine engine;
@Inject
public MailCollectorApp(final MailEngine setEngine) {
engine = setEngine;
}
public String getMail() {
var ret = "No mail found.";
if (!engine.getAllMail().isEmpty()) {
ret = Joiner.on(System.lineSeparator()).join(engine.getAllMail());
}
return ret;
}
public static void main(final String... args) {
var injector = Guice.createInjector(new DIModule());
var app = injector.getInstance(MailCollectorApp.class);
System.out.println(app.getMail());
}
}Let's analyze what's going on here...
Running the main method will create a Guice's injector, which is the context for all dependencies to live in. As we create it with an instance of our DIModule class, the injector's context will have the following dependencies configured in it:
As stated, in Development stage the MainEngine is a Lazy Singleton, plus, we configured the Set of MailService as Non-Singleton. That means that at this point, there's nothing instantiated in the injector context. All it has is instructions on how to instantiate.
The next step, asking the injector for an instance of MailCollectorApp will accomplish the following:
Guice will pick up the constructor in MailCollectorApp, as it's the only constructor.
As the constructor is marked with @Inject, Guice will look in its context for a dependency of type MailEngine.
It will find the RobustMailEngine configured, which is a Lazy Singleton.
While trying to instantiate it, it will pick up its constructor which is also marked with @Inject.
Guice will look for a suitable dependency with the type Set of MailService.
It will find the Set of GoogleService and MicrosoftService, which is a Non-Singleton.
After preparing the dependency graph, Guice will:
Create the set after instantiating both GmailService and MicrosoftService.
Instantiate the RobustMailEngine injecting the Set.
Instantiate the MailCollectorApp injecting the RobustMailEngine.
We then get our instance MailCollectorApp with everything we need in it, from which we invoke getMail to get all of our mail.
That's it, Guice in a nutshell. 😆
Now, Let's test the code...
I'm gonna start by saying, in regards to unit tests, if possible, always prefer not to use di frameworks in unit tests.
Unit tests are about testing small parts, units, of your application. You don't need the overhead of creating the di context, it will probably serve no purpose for you. You would probably be better off just instantiating the subject under test manually.
On the other end, if you talking about integration, or acceptance tests, or any other situation when you might need to test your application end-to-end, well, in that case, a good di framework could be your best friend.
That being said, for demonstration purposes only, let's move on to unit tests with di framework.
public final class MailCollectorAppTest extends AbstractModule {
private MailService gmailServiceMock;
private MailService microsoftServiceMock;
private MailService thirdServiceMock;
private MailCollectorApp sut;
private Faker faker;
@Override
public void configure() {
var listBinder = newSetBinder(binder(), MailService.class);
listBinder.addBinding().toInstance(gmailServiceMock);
listBinder.addBinding().toInstance(microsoftServiceMock);
listBinder.addBinding().toInstance(thirdServiceMock);
bind(MailEngine.class).to(RobustMailEngine.class).in(Scopes.SINGLETON);
}
@BeforeEach
public void initialize() {
faker = new Faker();
gmailServiceMock = mock(MailService.class);
microsoftServiceMock = mock(MailService.class);
thirdServiceMock = mock(MailService.class);
var injector = Guice.createInjector(this);
sut = injector.getInstance(MailCollectorApp.class);
}
@Test
@DisplayName(
"make the services mocks return no mail and validate the return string as 'No mail found'")
public void getMail_noMailExists_returnsNoMailFound() {
willReturn(emptyList()).given(gmailServiceMock).getMail();
willReturn(emptyList()).given(microsoftServiceMock).getMail();
willReturn(emptyList()).given(thirdServiceMock).getMail();
then(sut.getMail()).isEqualTo("No mail found.");
}
@Test
@DisplayName(
"make the services return legitimate mail and validate the return string as expected")
public void getMail_foundMail_returnsExpectedString() {
var mail1 =
GmailImpl.builder()
.from(faker.internet().emailAddress())
.subject(faker.lorem().sentence())
.build();
var mail2 =
MicrosoftImpl.builder()
.from(faker.internet().emailAddress())
.subject(faker.lorem().sentence())
.build();
var mail3 =
MicrosoftImpl.builder()
.from(faker.internet().emailAddress())
.subject(faker.lorem().sentence())
.build();
willReturn(List.of(mail1)).given(gmailServiceMock).getMail();
willReturn(List.of(mail2, mail3)).given(microsoftServiceMock).getMail();
willReturn(emptyList()).given(thirdServiceMock).getMail();
then(sut.getMail().split(System.lineSeparator()))
.containsOnly(mail1.toString(), mail2.toString(), mail3.toString());
}
}As you can see, all I did was create the injector with a different module than the one I've used for my app (DIModule).
In this case, I've extended the test class to be a module in itself and inject my mocks instead of the real GmailService and MicrosoftService, I've even added a third service, just for the kick of it. 😁
The RobustMailEngine was not mocked, because there was no real reason to do so, but it could have been easily replaced with a mock or a spy.
My test class behaved exactly like my main app, except for the services being mocks instead of real objects.
You can check out the code for this part of the tutorial in Github.
👋 See you in the next part of this tutorial 👋
רד האט היא החברה המובילה בעולם לפתרונות תוכנה מבוססי קוד פתוח לארגוני Enterprise. רד האט מבוססת על כוחה של קהילת הקוד הפתוח בפיתוח ואספקת טכנולוגיות Linux, Cloud, Container, ו-Kubernetes. אנחנו מסייעים ללקוחות לשלב בין יישומי IT חדשים וקיימים, לפתח יישומים רב-ענניים (multi-cloud), לבצע סטנדרטיזציה של מערכת ההפעלה, יחד עם אוטומציה, אבטחה וניהול של סביבות מורכבות.