At a high level, automatic garbage collection in Java works by:

But there’s a catch when it comes to how automatic garbage collection works in Java: there’s no guarantee when it will run, and there’s multiple reasons why this is:

So how can you hook into garbage collection? Well, objects created in Java inherit from the Object class, which means that all objects have certain methods that we can override: finanlize() is a method that is invoked by the garbage collector prior to the object being destroyed.

This might be a good place for you to invoke some business logic that you need to perform upon the object being deleted from memory, but remember: There is no guarantee when garbage collection will run, and therefore the logic that you put in the finalize() method of your object shouldn’t really be mission critical as it may or may not run when you expect it to. Also, garbage collection is generally an expensive task and we should really let the JVM do its things since it’s already highly optimized. (There really are very few reasons why you should be doing your own garbage collection in Java, and if you’re on the fence as whether or not it’s something you explicitly need to handle, you probably don’t.)

Furthermore, handling your own garbage collection is generally frowned upon, and if you do need to handle some kind of clean up activities for when objects are no longer needed, you should probably be building this logic into a service or a method that lives on the object that is going to be destroyed, or if you’re using Spring or Spring Boot, this is probably already managed for you to an extent.

Imagine having a remote control for your entertainment system. You can press the “play” button regardless of whether you’re playing a DVD or Blueray, streaming a movie, or listening to music. The remote acts as the interface, and the specific devices receiving the command handle the action in their own way (They are the objects). Polymorphism works similarly.

Why is Polymorphism Important?

Polymorphism offers several advantages:

• Flexibility: Code can adapt to different object types without needing to be rewritten for each specific case.
• Maintainability: As your program evolves, adding new object types becomes easier since the core logic remains unchanged.
• Readability: Code that leverages polymorphism is often cleaner and easier to understand because it focuses on the functionality rather than the specifics of each object type.

A Use Case: Animal Sounds

Let’s consider a scenario where you want to create a program that simulates animal sounds. You can define an abstract base class Animal with a method makeSound() that makes a generic animal noise. Now, create derived classes like Dog, Cat, and Bird that inherit from Animal and override the makeSound() method to produce their unique sounds (bark, meow, chirp, etc.).

// Base class
public class Animal {
  public void makeSound();
}

// Derived class - Dog
class Dog extends Animal {
  @Override
  public void makeSound() {
    System.out.println("Woof!");
  }
}

// Derived class - Cat
class Cat extends Animal {
  @Override
  public void makeSound() {
    System.out.println("Meow!");
  }
}

// Derived class - Bird
class Bird extends Animal {
  @Override
  public void makeSound() {
    System.out.println("Chirp!");
  }
}

public class AnimalSoundSimulator {
  public static void main(String[] args) {
    Animal[] animals = {new Dog(), new Cat(), new Bird()};
    for (Animal animal : animals) {
      animal.makeSound();
    }
  }
}

The above example is somewhat contrived and simplistic in nature, but it does convey the core concepts of polymorphism fairly well.

We have a base class of Animal, which defined a makeSound() method, and then several classes that extend the base class and then overwrite the behavior of the makeSound() method.

The animalSoundSimulator class simply defined a new collection of Animal objects (Since they all extend the Animal class, we can consider them to be Animals), and then loop over the collection and invoke makeSound() on each animal to see polymorphism in action.

Bonus: Extends vs. Implements

You’ll notice in the above that all of the classes like Cat, Dog, and Bird all extend the Animal class. This means that Cat, Dog, and Bird all, at a minimum, have at least the functionality of the class that they are extending, and in order for the magic to take place, you must override the methods that are defined in the class that is being extended. (The @Override annotation ensures that the method is being truly overwritten and not just overloaded, in which case strange behavior might occur and it might be difficult to debug.)

However, when it comes to implementing an Interface, the classes that are implementing the interface must conform to the methods outlined in the interface, however Overriding the methods defined in the interface is not a requirement. Also note that in the case of implementing an interface, the class that is doing the implementing must implement all of the behavior defined in the interface itself – Think of it as a contract of behavior.

Spring Boot heavily relies on annotations, similar to decorators when building an Angular front end application. Annotations are essentially metadata that are used to add context to what a class, method, or field does. This helps Spring Boot automatically configure Beans, manage dependencies, and handle other application configuration that we’d have to otherwise do manually when compiling our application.

One of these annotations is @Autowired. This annotation is a way for us to achieve dependency injection with next to no boilerplate code needed. It almost seems like magic because of how easy it is, and with that level of abstraction comes several caveats and pit falls when comparing this method of dependency injection versus traditional constructor injection.

Let’s first take a look at some of the benefits of using the @Autowired annotation:

• Reduce boilerplate code
  This is probably an obvious advantage and is the reason why some people tend to use @Autowired for any and every dependency needed: It’s so easy! All you need to do is simply add the @Autowired annotation to whatever field, constructor parameters, or setter methods you want to inject and you’re done! This also somewhat improves code readability because it reduces the amount of boilerplate code you have to write.
• Loose Coupling
  By injecting components at runtime we can achieve loose coupling which is a great advantage when it comes time to test our application via unit testing. Though you will likely have to mock or provide the appropriate test beans when running the unit tests.
• Automatic dependency lookup
  Spring Boot will find and manage the appropriate beans to inject based on their types and their annotations. You won’t have to create or locate the required Beans yourself while can reduce the likelihood of errors and added complexity. (More on why this could be bad in a little bit)

And let’s discuss some of the drawbacks when using @Autowired:

• Implicit dependencies
  Sure, @Autowired helps to reduce the amount of boilerplate required, it also can make it more difficult to truly discern what the class is doing and what exactly it relies on in order to function as intended. This could pose as a real challenge for future developers who are tasked with maintaining/enhancing the application in the future – they will have to take more time to reason about the code you’ve written.
• Less control
  By reducing the amount of boilerplate code needed, one of the trade offs is giving up some level of control. What if for some reason you have multiple beans of the same type? Spring Boot might not pick the correct bean and as a result cause the application to break or not function correctly. You can get around this by specifying qualifiers, but if you’re going down that route, why not rely on constructor injection?
• Circular Dependencies
  It is very easy to get yourself into a situation where service A depends on service B, which depends on service A. You have to be very careful not to create a circular dependency and you also have to ensure the order in which bean creation is taking place is correct. This is easier said than done in a large application with dozens and dozens of services, controllers, and repositories.

With that said, when should we be using the @Autowired annotation to handle dependency injection? It’s hard to come up with an iron clad rule – If you’re building a small CRUD application and are just working towards an MVP and you don’t have many services, then probably using constructor injection is the way to go in this case. If you’re working on a larger enterprise-level application, then most likely you will want to avoid using @Autowired in most cases. If you have a service that relies on half a dozen or more other services, there might be no other sensible way aside from using @Autowired – though this indicates code smell: Why does this service rely on so many other dependencies to function? Is it doing too much and can be broken into smaller chunks?

Finally, let’s discuss some of the advantages of using traditional constructor dependency injection, as well as some of its draw backs (You can probably guess what they are based off of the pros and cons of using @Autowired)

Benefits of constructor-based dependency injection:

• Clear dependencies
  Dependencies are declared directly in the constructor, which makes them clearly visible and identifiable. This will allow for better readability in the future and reduces the risk of missing or hidden dependencies. Sometimes being more verbose is better, and this is one of those cases.
• Fail-Fast
  If a mandatory dependency is missing, the constructor initialization fails which prevents the creation of half-baked objects. Even better, you avoid the wrong bean being injected if you wind up with two beans with the same name/type.
• Encourages immutability:
  If you’re using the functional programming paradigm when building your application or want to stay true to true OOO principles, using constructor-based dependency injection as opposed to @Autowired is basically a must.
• Testability
  Generally, constructor-based dependency injection is easier to test. You can more easily mock dependencies during unit testing by passing mock objects into the constructor.

And finally, let’s take a brief look at some of the drawbacks of using constructor-based dependency injection (Hint: there really aren’t many):

• Boilerplate code
  This is probably the biggest one for most people – it requires a lot more code than just simply using @Autowired to handle dependency injection, but in most cases the additional code is worth it. You could even explore using Lombok if you wanted to still use constructor-based dependency injection but keep the amount of boilerplate code at bay. Just be careful because you’re introducing yet another layer of abstraction by using Lombok. You have to find the right balance for your code base and the team you’re working with.
• Limited Flexibility
  There is really no way to handle optional dependencies when using constructor injection so situations that require dynamic configuration changes might pose a problem. The answer to this is just more code in the way of more objects and classes. Again, this is a trade-off between how easy the code is to read and maintain and how quickly you can get the code working.

At it’s most basic, the concept of IoC sets out to reverse the control between two classes via a third party (When developing modern Java applications this is usually Spring!). If we have two classes – a User class, and a Database class, the User class would directly depend on the Database class in order to save any data to the database. What if we change databases in the future and migrate away from MongoDB to Postgres? Sure, in a small application this wouldn’t be too difficult, but what about in an enterprise-level application with hundreds of thousands of lines of code and dozens of developers working on the same code base at the same time? We can do better! Enter Inversion of Control.

Before diving into an example, another key benefit to address regarding IoC is that without it, our application would be considered tightly coupled, and next to impossible to unit test. Why? Well, because in order to do so, you’d have to mock an entire database in the User/Database scenario from above, and that’s really not practical, nor is it in the spirit of unit testing. implementing IoC allows us to instead loosely couple our application and actually unit test our code without the need to mock an entire database.

First, let’s look at a tightly coupled example that does not implement IoC:

//User.java

public class User {

    MongoDb database;

    public User() {
        database = new MongoDb();
    }

    public void add(String data) {
        database.save(data);
    }

}

//MongoDb.java

public class MongoDb {
    
    public void save(String data) {
        System.out.println("The data you provided has been saved! " + data);
    }
}

A pretty straight forward example. When we create a new User object, we are creating an instance of a MongoDb object each and every time. That MongoDb instance comes with a save method that takes in a string and in this example just returns a mock string back, using the same data that was passed in.

In this example, performing a unit test is extremely difficult because our User objects directly rely on an instance of MongoDb! There’s really no way for us to pass in a mock instance of the database since it’s being created at the same time as the User object – hence the term tightly coupled.

Also, if in the future the decision is made to utilize another database, it’s not easily done since we’ve essentially hard-coded the User class to depend directly on the MongoDb class. All of the subsequent methods in the User class would have to be updated.

Let’s take a look at an example employing the IoC paradigm in which we pass in MongoDb as an argument to the User constructor… Sounds like unit testing would be a little easier if we’ve already been given a database! We’re going to reverse the flow of control and instead of the User class controlling the database, we’re going to tell it what to do by passing a pre-existing database into its constructor… We’re inverting the control!

//User.java

public class User {

    MongoDb database;

    public User(MongoDb database) {
        this.database = database;        
    }

    public void add(String data) {
        database.save(data);
    }

}

Every time a user Object is created, we’re passing in a pre-existing instance of a MongoDb instance! Unit testing can be carried out since we’re being given a database each time we create a User! (In unit testing we’re only testing a single unit of code – imagine having to mock a database and hope you got its implementation right so you don’t run into unexpected bugs?)

Let’s take the above example a step further. We’re on the right track in terms of abstracting away where a new instance of MongoDb is being created, thus allowing us to unit test our code. But what if our team decides to migrate away from MongoDB and use MySQL instead?

Here we go again! The User class is expecting a MongoDb instance to be passed in! Let’s fix this by implementing a generic database interface that will force its behavior on whatever class we implement it in. Remember: an interface is a contract of behavior, so where ever it is implemented, we are guaranteed to, at the very minimum, have access to whatever the interface defines.

Let’s create a generic interface that all databases will implement:

//Database.java

public interface Database {
    void save(String data);
}

Where ever we implement this interface, we’re guaranteed to at least have a save method that doesn’t return anything, but takes in a String. Now let’s update our existing MongoDb class to implement this new interace:

//MongoDb.java

public class MongoDb implements Database {
    
    public void save(String data) {
        System.out.println("The data you provided has been saved! " + data);
    }
}

The change is subtle, but this is good as we’re getting closer to a really robust solution. Now the MongoDb class implements the Database interface. It must have a save method that doesn’t return anything and takes in a string as an argument. If not, the code will not compile.

Finally, let’s update our User class to now rely on a generic Database object rather than a MongoDb class, a MySql class, Oracle class, etc.

//User.java

public class User {

    Database database;

    public User(Database database) {
        this.database = database;        
    }

    public void add(String data) {
        database.save(data);
    }

}

We can clearly see that our User class doesn’t really care about what kind of database is being passed in… So as long as it implements the Database interface, we are good to go and can utilize it in the class! We have achieved loose coupling and our program is much more robust than when we began our example.