DEV Community: Emanuel Trandafir

MVC Violation Ruined His Tic-Tac-Toe Game!

Emanuel Trandafir — Sat, 28 Jan 2023 15:46:11 +0000

1. Overview

My friend is working on a cool new VR game and he asked me to help with some tips and tricks on how to test it.
PS: I was kidding with the VR part, it will be a console tic-tac-toe game:

public class Player {
    public static final int MAX_NUMBER = 100;
    public static final int MIN_NUMBER = 10;
    private final Scanner scanner = new Scanner(System.in);

    public int getNextMove() {
        System.out.println("please, type your next move and hit <enter>");
        int input = scanner.nextInt();

        while(input < MIN_NUMBER || input > MAX_NUMBER) {
            System.out.println(String.format("the number must between %d and %d! try again...", MIN_NUMBER, MAX_NUMBER));
            input = scanner.nextInt();
        } 
        // other game-related logic here
        return input;
    }
}

Even though it is possible to do some "hacks" and test this method, ugly tests may be symptoms of bad design - so it's always a good idea to refactor the code first.

2. MVC Violation

Firstly, there is no separation between the model, view, and controller. This leads to a lot of coupling between the game logic and the input that comes through the terminal.
The best way to eliminate his direct coupling is to apply the Dependency Inversion Principle. In this case, let's declare an interface that allows user communication. We'll call it "PlayerView":

public interface PlayerView {
    int readNextInt();
    void write(String message);
}

The Player object will only know about this interface. At this point, we only depend on our own classes (we no longer use System.out, System.in, Scanner … etc):

public class Player {
    public static final int MAX_NUMBER = 100;
    public static final int MIN_NUMBER = 10;
    private final PlayerView view;

    public Player(PlayerView console) {
        this.view = console;
    }

    public int getNextMove() {
        view.write("please, type your next move and hit <enter>");
        int input = view.readNextInt();

        while(input < MIN_NUMBER || input > MAX_NUMBER) {
            view.write(String.format("the number must between %d and %d! try again...", MIN_NUMBER, MAX_NUMBER));
            input = view.readNextInt();
        }
        return input;
    }
}

3. Dependency Inversion

How do we make it work? Well, to make it work the same as before, we now need to create an implementation of the PlayerView interface and copy the old functionality:

public class ConsoleView implements PlayerView {
    private static final Scanner scanner = new Scanner(System.in);

    @Override
    public int readNextInt() {
        return scanner.nextInt();
    }

    @Override
    public void write(String message) {
        System.out.println(message);
    }
}

As a result, when the game will be initialized, we'll need to create the players based on a ConsoleView, like this:

Player player = new Player(new ConsoleView());

4. Writing a Mock

What are the gains? After this inversion of the dependency, the Player class can be tested with ease. For instance, we can use a mocking library to mock the view and allow us to test the rest of the functionality in isolation. In java, mockito is a popular and powerful tool for this.
On the other hand, blindly using libraries and frameworks might make us lose sight of the bigger image. So, from time to time, it is better to code the solution ourselves instead of bringing in a 3rd party library.
Therefore, let's create a very simple version of a mock object. We can do this simply by writing a new implementation of the PlayerView interface:

public class MockView implements PlayerView {
    private List<Integer> mockedUserInputs = new ArrayList<>();
    private List<String> displayedMessages = new ArrayList<>();

    @Override
    public int readNextInt() {
        return mockedUserInputs.remove(0);
    }

    @Override
    public void write(String message) {
        displayedMessages.add(message);
    }

    public List<String> getDisplayedMessages(){
        return displayedMessages;
    }

    public void mockedUserInputs(Integer... values) {
        mockedUserInputs.addAll(Arrays.asList(values));
    }
}

As we can see, we'll use two lists
mockedUserInputs will be specified in the test setup. Each time somebody will call readNextInt(), the mock will return the next value from the list.
displayedMessages only has a getter. This list will be used to store all the messages we are trying to print. This can be useful in case we want to check that we are displaying the messages correctly.

5. Unit Testing

Finally, let's use our tailor-made mock class and write some unit tests:

@Test
void shouldAskUserToEnterNextMove() {
    //given
    MockView mockedView = new MockView();
    mockedView.mockedUserInputs(11);
    TestablePlayer player = new TestablePlayer(mockedView);

    //when
    player.getNextMove();

    //then
    List<String> displayedMessages = mockedView.getDisplayedMessages();
    assertThat(displayedMessages)
        .containsExactly("please, type your next move and hit <enter>");
}

@Test
void givenInvalidInput_shouldAskUserToReEnterTheMove() {
    //given
    MockView mockedView = new MockView();
    mockedView.mockedUserInputs(5, 22);
    TestablePlayer player = new TestablePlayer(mockedView);

    //when
    player.getNextMove();

    //then
    assertThat(mockedView.getDisplayedMessages())
        .containsExactly(
            "please, type your next move and hit <enter>",
            "the number must between 10 and 100! try again...");
}

@Test
void shouldReturnUsersMove() {
    //given
    MockView mockedView = new MockView();
    mockedView.mockedUserInputs(44);
    TestablePlayer player = new TestablePlayer(mockedView);

    //when
    int userMove = player.getNextMove();

    //then
    assertThat(userMove)
        .isEqualTo(44);
}

6. Conclusion

In this article, we've learned about the MVC design pattern. We applied the Dependency Inversion Principle (the "D" in "SOLID") to decouple the controller from the view.
Finally, we were able to test it and we learned how to create a very simple mock object to simulate the user interaction.

Thank You!

Thanks for reading the article and please let me know what you think! Any feedback is welcome.

If you want to read more about clean code, design, unit testing, functional programming, and many others, make sure to check out my other articles.

If you like my content, consider following or subscribing to the email list. Finally, if you consider supporting my blog and buy me a coffee I would be grateful.

Happy Coding!

My New Year Resolutions as a Backend Developer

Emanuel Trandafir — Wed, 25 Jan 2023 20:46:08 +0000

I’ll walk you through my goals for this upcoming year, from a technical perspective.

1. Focus on Design, Not on Frameworks

One of my goals for the future is to focus on the design of the projects and invest less time into learning all the ins and outs of cool-looking framework and libraries.

Before using any new library, I will carefully consider the problem at hand and evaluate whether the library is the most effective solution, as well as compare it to a potential solution using plain Java.

I recently published an article on this topic, in which I share some insights from Uncle Bob Martin and Christion Gorman before offering my own perspective on the matter. If you are interested in finding out how to Quit Believing in Framework Magic, feel free to read through the article and let me know what you think!

To summarize, excessive reliance on frameworks and libraries can obstruct the clarity of our business logic, expressed in code. As the saying goes, “clean code reads like well-written prose.” If much of our code is scattered across configuration classes and properties files, it will be difficult to achieve this level of clarity.

2. Embrace The Domain

If we are hesitant to fully understand and embrace the domain we are working in, it becomes challenging to effectively communicate the business cases through code. It is important to not shy away from the domain and to avoid relying solely on technical jargon.

This is a funny website that generates names for your Java classes: try hitting “enterprisfy” a couple of times :) It's mindblowing how many words we can use without truly conveying any meaningful information.

In conclusion, my second new year resolution is to dive deeper into practices such as D.D.D (domain Driven Design) and B.D.D (Behaviour Driven Development). Furthermore, I believe Uncle Bob’s idea about Screaming Architecture is really interesting and it can guide us in this direction.

3. Write Better Code Using Functional Style

In my opinion, a strong foundation of tests is key to good design. Especially when incorporating the considerations previously mentioned and using B.D.D.

For example, placing core logic into pure functions makes it much simpler to write executable specifications and use parameterized tests, which involve providing sets of input and expected output values.

Moreover, I am planning to start applying the Command-Query Separation Principle more rigorously and use immutable objects whenever possible.

Conclusions

These are the main practices I want to focus on in 2023. I believe they supplement each other nicely. The functional style will allow me to write better tests in a nice B.D.D. fashion, where you can focus on the use case and not on the implementation details.

Moreover, by eliminating unnecessary frameworks and libraries, we can work towards prioritizing the clarity of business logic in code. This aligns with Uncle Bob’s idea of “Screaming Architecture” where the business use cases are clearly and immediately evident.

Thank You!

Thanks for reading the article and please let me know what you think! Any feedback is welcome.

If you want to read more about clean code, design, unit testing, functional programming, and many others, make sure to check out my other articles.

If you like my content, consider following or subscribing to the email list. Finally, if you consider supporting my blog and buy me a coffee I would be grateful.

Happy Coding!

Spice Up Your Junior Side Projects With These Five Flavours

Emanuel Trandafir — Sun, 22 Jan 2023 18:10:31 +0000

Each of your personal projects should have these five aspects in order to get you that first Junior Developer role.

Having an empty Git repo can be intimidating. This is mostly because you don't have work experience and your Git repository is barren as the desert of Arrakis. It's always a good idea to enrich your resume with personal projects when preparing for an interview. But, what should these projects be?

Uploading applications you wrote following tutorials can be a starting point, but it won't get you far. You'll end up with the same projects as every other junior out there.

Therefore, I have decided to write down some advice that I would've liked to receive when I was building up my junior resume. These are my personal opinions, feel free to read through the article and decide for yourself what to include in your projects.

1. Choose a Good Subject

Avoid mimicking endless online tutorials with tic-tac-toe games or to-do lists.
Instead, try making the project about yourself: about things you are passionate about. It can be something about the sport you practice, the music you listen to, or about coding itself.

Some people may say the employer will not be interested in this topic and that you should implement something that is relevant to them - for instance, an issue tracking application.
I believe that choosing a personal and original project idea might help you in the long run. Firstly, because you know exactly what to build and what features you would like to have. Secondly, you can use the extra motivation of working on something you're passionate about to get the project done.

2. The Project is Complete

Working software! Start from a small and simple idea and add complexity along the way.
It is common between developers to start never-ending personal projects. Don't fall into this trap! Keep your tasks small and simple.
Use feature branches and make sure you can always start the app from the master branch easily, for a quick demo.

3. Clean Code

The interviewer will look over this code. Try to keep it as clean and well organized as possible.
If you are not sure about it, read some articles about coding conventions and best practices and double-check if you are following them.
For instance, I wrote a short article about the SOLID Principles - understanding them will greatly improve your code quality.

Your code should be as SOLID as a rock. Photo by Winggo Tse on UnsplashAdditionally, you can use IDE extensions for code quality such as Sonar Lint. This way, you can eliminate code smells and potential bugs.
After that, ask a friend who is already working as a developer for a code review. If you don't know whom to ask, send me a message - I'll be happy to take a look!

4. The Project is Accessible

You will invest time and effort to ensure the code quality is high. Therefore, you'll have to make sure the source code is available and up to date, in a public Git repository.
Photo by Roman Synkevych 🇺🇦 on UnsplashMoreover, the interviewer can see not only the code itself but also that you can efficiently work with Git.
You can have a readme.md file where you present the general idea of your project and the design of your application.
Besides, if your project is a Web Application, you can even deploy it to a free hosting platform such as Heroku. I believe this would be big a plus.

5. Be Realistic

Your idea should have a real-world application. Avoid coding games and try to focus on small things that can help you on a daily basis.
For instance, you can think of an application that you use often and try to implement a feature that is missing.

Explaining the Open-Closed Principle to the Rubber Duck With a Hands-On Exercise

Emanuel Trandafir — Fri, 20 Jan 2023 19:21:13 +0000

Understanding how the Opened-Closed principle, immutability, encapsulation, and unit tests are working with a simple, hands-on, interview problem.

Overview

FizzBuzz is a common interview question for junior developers. The initial requirement is to iterate through a list of numbers from 1 to 100 and print in the console:

Fizz - if the number is divisible by 3
Buzz - if the number is divisible by 5
Fizz Buzz - if the number is divisible by both 3 and 5 the number itself if no criteria were met

After that, the interviewer often adds extra requirements and use-cases, to see how easy it is for you to adapt and implement the new features.

The Design

Even though it can be tempting to start coding using a bunch of if statements and solve the problem quickly, let's try to take a step back and think about it first.

Firstly, we want to show that our code is testable. Asserting the console output can be hard and it will clutter the tests. Therefore, we'll try to separate the method which converts a number to the desired string from the one that writes the result into the console.

Secondly, the dividers are a potential point where the requirements might change. Consequently, we'll try to allow the creation of new dividers without affecting the rest of the code - conforming to the Open/Closed principle.

The Implementation

Let's start with the Divider class. It has a String "output" field and an integer "divisor".
They are both private and final, immutable. This means that, once a Divider is created, we can no longer change its output or the way is checking if the output needs to be printed.

public class Divider {
  private final String output;
  private final int divisor;

  public Divider(String output, int divisor) {
    this.output = output;
    this.divisor = divisor;
  }

  public boolean divides(int multiple) {
    return multiple % divisor == 0;
  }

  public String getOutput() {
    return output;
  }
}

As a result, we will be able to create a list of Divider objects like this:

List<Divider> dividers = List.of(
    new Divider("Fizz", 3),
    new Divider("Buzz", 5)
);

Now, let's take a look at the FizzBuzz class that s using these dividers:

For a given number, we'll concatenate the output of its dividers or return the number itself if none were found.

Unit Testing

It is now very simple to test the getOutput() method. In my case, I have used Junit5's parameterized test that allows me to specify pairs of input and expected output - but can easily be done manually in any testing framework:

class FizzBuzzTest {
  List<Divider> dividers = List.of(
    new Divider("Fizz", 3),
    new Divider("Buzz", 5)
  );
  FizzBuzz fizzBuzz = new FizzBuzz(dividers);

  @ParameterizedTest
  @CsvSource(value = {
    "1:1",
    "2:2",
    "3:Fizz",
    "5:Buzz",
    "15:FizzBuzz",
    "16:16"
  }, delimiter = ':')
  void getOutput(String input, String expected) {
    int number = Integer.parseInt(input);

    assertThat(fizzBuzz.getOutput(number))
      .isEqualTo(expected);
  }

}

The Flexibility

Even if it doesn't look like much, this structure offers us a lot of flexibility.
We can add new Dividers just by creating new instances of the Divider object. For instance, we can print "Foo" for multiples of 7 with the code below:

List<Divider> dividers = List.of(
    new Divider("Fizz", 3),
    new Divider("Buzz", 5),
    new Divider("Foo", 7)
);
FizzBuzz fizzBuzz = new FizzBuzz(dividers);

We can also remove dividers without touching the "production" code: we just need to remove them from the list when instantiating the FizzBuzz object. The various dividers are now simple plugins for our application.

Furthermore, we can change the order of outputs of the resulting string just by changing the order of the dividers from the list.
All this flexibility of changing the behavior of the application with minimal changes is a result of conforming to the Open/Closed and Single Responsibility principles.

Conclusion

In this article, we implemented a simple FizzBuzz while focusing on good coding practices, design, and principles.
Following the SOLID principles, especially the first two, and keeping an eye on testability lead to a decoupled and flexible design where we can easily adapt to new requirements with minimal risk.
In the next article, we'll see how to handle unexpected changes in requirements and how to use dependency inversion and polymorphism to solve the implement them.

Thank You!

Thanks for reading the article and please let me know what you think! Any feedback is welcome.

If you want to read more about clean code, design, unit testing, functional programming, and many others, make sure to check out my other articles.

If you like my content, consider following or subscribing to the email list. Finally, if you consider supporting my blog and buy me a coffee I would be grateful.

Happy Coding!