CDI Introduction and Exploring Polymorphism [Video]
This post and video discuss why we should use CDI and explains how to explore the Jakarta EE to use several patterns such as the SOLID principle.
Join the DZone community and get the full member experience.
Join For FreeAs software architects and designers, we have a common goal: simplicity. We want to archive success, mainly because the clarity in the code guarantees a readable and maintainable code. We seek several articles, books, videos, and literature to archive this, such as "Effective Java," "Clean Code," "Design Pattern" by GoF, and so on. Doing it bare-handed is pretty hard: we explore tools to make our life easier, mainly when discussing enterprise design architecture. To help, we're lucky to have CDI to make our life easier.
CDI is a Jakarta EE specification that works as glue in the platform. As defined in the specification:
Jakarta Contexts Dependency Injection, CDI, specifies a means for obtaining objects in such a way as to maximize reusability, testability, and maintainability compared to traditional approaches such as constructors, factories, and service locators (e.g., JNDI).
The best way to think about the CDI is a tool to make it easier or a bridge to bring a clean code. CDI enables you to get several good practices on OOP, such as the SOLID principle.
SOLID are five regulations of OOP class design. They are regulations and best practices to follow while designing a class structure. These five guides help us understand the need for specific design patterns and software architecture in general.
It is an excellent step to start a good start. As a reminder, SOLID represents:
- The Single Responsibility Principle
- The Open-Closed Principle
- The Liskov Substitution Principle
- The Interface Segregation Principle
- The Dependency Inversion Principle
It looks complex at first view; however, thanks to CDI, it will accelerate your developer experience.
We can explore the dependency injection using the CDI engine as we wish. Furthermore, the "C" in CDI matters especially because the context makes sense, such as the defined scope. CDI provides the following scopes, and this scope describes the lifecycle of the object.
- Request Scoped
- Application Scoped
- Session Scoped
- Conversation Scoped
This scope is powerful for stateless and stateful objects where we will put more priority on the stateless one.
With CDI, we can explore the dependency injection with context. Besides that, we can inject an implementation without the client noticing where the instances come from.
CDI allows us to inject concrete class and interface where it will look to the specific implementation. CDI will connect it automatically without any instruction when there is one interface to one implementation.
It is always essential to highlight that we must explore the KISS principle, so when we don't need an interface, don't use it. However, sometimes it is necessary, and CDI helps you with it.
CDI also provides features to authorize work with an interface with multiple implementations. You can use the Name
annotation or create your annotation with the CDI qualifier.
This video will explain more about why to use and explore the features of CDI. In addition, it discusses how to archive a clean and maintainable code with this specification. The goal is not to exclude the good OOP principle, but rather, the opposite: it will accelerate to evolute the code design in a pretty easy way with CDI.
The video content includes the following:
- Why use CDI?
- Introduction of CDI
- How to start with CDI?
- The scope introduction
- The injection introduction
- How to handle multiple implementations with Named
- How to handle multiple implementations with Qualifier.
Opinions expressed by DZone contributors are their own.
Comments