Dependency Injection – Refactoring of the project

We are continuing the dependency injection section, in this article we will refactorize the code from the previous entry and, as we remember, that code was not very friendly to read, test and expand. Today we will try to change it 🙂


First we have to refactorize this code to have what to inject, so you can come to the conclusion that we use a dependency injection to and satisfy solid rules, which means that dependency injection somehow suggests that we follow these rules.

At the beginning, let’s see how the classes of the characters have changed, namely the Thief, Mage, Barbarian and Paladin classes, and as we remember in that example, these classes inherit from the concrete class and should not. I dare even think they can not, amen.

Let’s see how you can deal with it. With the examples of the corrected code I will also say what in the next article from the revised code we will still improve (a litttle bit pomp and circumstance ) already using dependency injection 🙂

So that you do not have to look at the previous article how these classes looked I will paste here, they looked like this:

And now we changed them to something like:

As you can see now, these classes implement the interface, so they depend on abstraction and the variables are better insulated with the implemented interface.

Let’s move to distributing skill points after choosing a class.

The code before the changes from the previous example looks like this:

Well, there is some tragedy 😥 this method does more than one thing, so it will be hard to understand and to expand and it is very hard to test.

And now the code after changes:

Does not it look better? All instances of the character classes are separated into one class as it should be, so we have a lot easier to understand and test.

However, this is not what I want, we create instances of all classes of characters, and as we know, the user will choose only one class, but we do not know which class and methods are separate for the distribution of skills for each class. It would not be better to create only one class that the user will use and only one method of distributing skills?

In the next article you will see how dependency injection makes life easier 🙂

Let’s see what tests look like in this class.

We check skills after selecting a class, it is good to write tests for methods that accept some arguments and return some, but we have an exception because these methods operate on two variables and all code is organized, just call the methods distributing skill points and check the total amount skills in the character class we chose, so these methods are still easy to test.

However, there are a lot of these tests if there was only one method for distributing skill points, there would be only two tests. But calmly, we’ll do all this in the next article using dependency injection 🙂

The methods validating the password and login accept and return arguments, so in this way, as described above, we will write tests to them.

Without tests, you can sometimes be surprised why and what does not work after the change … 😐

Let’s see, what is the class for validating login and password?

Code for validating the password and login before the changes.

Here is also a tragedy 😥 everything thrown into one method, it’s hard to read, also fear to move here something because you can not write tests. 😐

Let’s see now how it looks after the changes. I divided it into two classes validating the password and login separately.

Password validating class:

And the validating class of the login:

It already looks a lot better :), validation of the password and login have been separated into separate classes which is more readable and easier to develop and easy to test. Let’s see how tests look like to them.

Tests to the LoginValidator class

And tests to the PasswordValidator class

And now we will see if all tests through to the validation of login and password as well the tests that check the correct distribution of skill points.

As you can see they pass 🙂

It’s better to ensure that after writing 100 lines of code everything works 🙂

At the end, let’s see the main GameServer class

In the RegisterUser() method, if the methods validating the login and password return us the condition true, we register the user, if any of the methods returns false, we display the error.

In the CreateCharacter() method, depending on the passed class, we give out skill points. You could use the Strategy pattern in this method to get rid of these if-s, but there is another better way related with the dependency injection. This is also in the next article 🙂

In the constructor, we pass class objects that we need, but we pass them to specific class types that should not be done.

There is a way for these objects to depend from abstraction, but about this in the next article.

And the client who uses the GameServer class.

I wanted to display skill points before and after the deal so that everything was understandable.




There is still a lot to improve, including tests. In the next article, we will improve everything using dependency injection. And we will further refactor this code 🙂

Link to github with the whole code from this article:–refactored-game-project

This content also you can find on medium:

As a standard, I remind you about the newsletter, which I send notifications about new entries and additional information about the IT world in general.🙂

And NECESSERILY join the DevmanCommunity community on fb, part of the community is in one place 🙂

– site on fb: Kowalski

– group on fb: DevmanCommunity

Ask, comment underneath at the end of the post, share it, rate it, whatever you want🙂.

If that post was useful for you share it with your friends :)

Post a comment

Notify about