The CDI Event: How to Achieve Success on the Open-Close Principle

When we talk about a good design on Java and OOP, the first thing that might come to mind is the SOLID principle; it brings five easy steps or at least a sign if the code is going in the right direction. CDI for sure helps you to archive the code in the proper order. Today, we'll explain how to take advantage of CDI with CDI and get the Open close principle.

If you forget the SOLID principle, don't worry, we'll put it here to remember what does mean SOLID:

• The Single Responsibility Principle
• The Open-Closed Principle
• The Liskov Substitution Principle
• The Interface Segregation Principle
• The Dependency Inversion Principle

Today with CDI Event, we'll archive the Open closed principle. The Open close guide is based on the quote:  "software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification."

It means we can add fresh features since we don't modify the core all the time. To make it clear, we'll use a sample scenario. 

Imagine a Journalist who will receive news, curate, and promote it on several media such as TV, Media Press, newspapers, social media, and so on.

public class News implements Supplier<String> {

    private final String value;

    public News(String value) {
        this.value = value;
    }

    @Override
    public String get() {
        return value;
    }

    @Override
    public String toString() {
        return "News{" +
                "value='" + value + '\'' +
                '}';
    }
}

With the News entity, the next step is to create the media to publish this news. To streamline the first step, we'll provide only Magazine and Newspaper.

public class Magazine {

    public void receive(News news) {
        System.out.println("Publishing the news on magazine: " + news);
    }
}


public class NewsPaper {

    public void receive(News news) {
        System.out.println("Publishing the newspaper: " + news);
    }
}

Done, we have both the news and the media to press. The end step in this process is to create who will receive the information and publish it to the existing press: the Journalist.

@ApplicationScoped
public class Journalist {

    @Inject
    private Magazine magazine;

    @Inject
    private NewsPaper newsPaper;
    
    public void publish(News news) {
        magazine.receive(news);
        newsPaper.receive(news);
    }
}

Yeap, we got our demo working; however, what is wrong with this code? What do we need to do? Let's imagine we need to add a new press type, such as social media. Yeap, create a class and modify the Journalist again, and if it appears, another one. Change the Journalist again and again. 

So every time a new media type appears, we need to change the Journalist entity, so our code is broking the open-close principle. 

We need to ensure that every time we add a new media type, we do not modify the Journalist again. Hopefully, we have design patterns to make our life easier, and we have the Observer Pattern on this repository. 

CDI promotes it with the event where we can fire an event to multiple observers; therefore, we no longer need to modify the entity to a new media type. Indeed, the entity does not even know who will watch this news. It is its job only to curate and then publish it.

In this video, we'll explore the power of CDI events and how to achieve success in a robust and clean code design on your code with it.