Growing Object-Oriented Software, Guided by Tests

It’s been awhile since my last post. Recently, there have been many conferences and meetups I had pleasure to spoke at. Making presentations, carrying out research, readings, conducting reviews, etc., everything takes time. I need to admit that I like each part of this process, because I always learn something new. Even if I’m reading the same materials, blogs, books, even if I’m thinking once again about the same topic, I always find some things I didn’t noticed before.

LoGeek Night Krakow!

Do you like cold beer and hot pizza?
Are you passionate of programming and code quality?
Do you want to listen good presentations and talk with interesting people?
Or maybe you just want to meet your favourite blogger and talk with him about Code Review? :)

If you answered 'yes' at least once don't wait no longer. Don’t miss your chance and register today!
Let's meet at LoGeek Night in Kraków!

When? November 26th, 7pm.
Where? Pauza in Garden, Rajska 12, Kraków


See you soon :)

Tell, don't ask

about rules and principles

Some time ago I wrote about the Law of Demeter, about the advantages of following this law. Today I would like to write about the “Tell, don’t ask” principle. The principle that is, at least in my opinion, the starting point for the mentioned law. Following LoD is one of the consequences of applying the TDA principle.

Ok, but what should we tell and what shouldn’t we ask about anyway?

33rd Degree 4 Charity - let’s meet there!

“Programming conference with charitable cause” is what 33 Degree 4 Charity is all about. This year the organizers will help the following foundations: Fundacja mam Marzenie, Rak’n’Roll, Szlachetna Paczka and Devoxx4Kids. All of the collected funds will go to these charitable organizations.

And this year I have pleasure to support them and give a talk at the event. I will be talking about Code Review and the ways to do it better. If you would like to hear me or talk with me... just be sure to be there :)

The conference will be held in Wrocław and will take two days - 30.11 and 01.12.

If you have not registered yet, don’t hesitate and do it here!

Where's the law?

If you would like to describe Law of Demeter in one sentence, it would go like that: “talk only with your (closest) friends”.
In full form it tells that a method of particular object can call only methods that belong to:

• the same object,
• any object that is an attribute of this object,
• any object that was passed as a method’s parameter
• any object that was locally created.

OOP: How to do it right. What the method is?

Some time ago I wrote about objects' attributes. Parts that identify them. However, the objects are exactly like us - it’s our behavior that determines who we are, makes us who we are. This behavior and reactions are the things that really interest others. Would Sebastian be the same annoying person if his name were different? Assuming there's no magical power in our names he probably would.

Don't get me wrong, I don't want to minimise the importance of object's attributes. The behavior of the object often depends on them, e.g. if the age is one of person’s attributes, it's clear that it determines many activities that the person can or cannot do.

Test Double Patterns

Some time ago I wrote an article about the consequences of using Test Double, but there was nothing about Test Double Patterns, nothing more than a simple list. Today I would like to change it and explain the differences between those patterns.

As I wrote in mentioned article that:

Test Double are patterns that allow us to control dependencies between the tested unit. To make it possible to provide wanted behavior whenever we want to or/and verify whether wanted behavior occurred.

So now when you have been reminded of the basics, we can move to the interesting part - let’s look at Test Double Patterns.

main method should not be your test strategy

Nowadays many developers know about advantages of tests. We know how they’re helping us when we need to change or refactor the code. We also know how helpful they can be when we want to describe or show how a particular functionality works.
We are encouraging to write tests. To cover your code. To decrease uncertainty.

Yet, I’m still seeing a lot of articles where someone shares his knowledge about particular features and… he shows how the code works using main() method:

public class WhateverApp {
    public static void main(String[] args) {
        DescribedFunctionalityProvider provider = new DescribedFunctionalityProvider();
       
        Result result = provider.showHowYouDoingThings();
 
        System.out.println(result.showThatReallyWorks());
    }
}

I’ve got one simple question – why?

Do you really want to test it?

I’m probably not the only one who had a chance to participate in deliberations over whether some private method should be tested (because it’s worth it) or not (because we shouldn’t test private methods). I’m not writing about pure theoretic conversations while you’re filling your cup of coffee and talking with your colleagues. I believe that in those moments most of developers would tell you a firm NO.

But what about situations when you are working with real code? When all those rules and principles are not so strictly followed? Would they also say NO so firmly? Based on my experience, I can tell you they wouldn’t. At least not always.

Ok, but should they? Should we? Or is it yet another nice-to-follow rule the observance of which depends on context?

OOP – how to do it right? – attributes

primitive types and objects

The values of attributes of particular objects are the things that allow us to recognize a specific object to determine whether two objects are different or similar. It lets us identify instances of the class.

We can categorize attributes into two types:

• Primitive types: byte, short, int, long, float, double, boolean and char.
• Objects – they’re implemented as an aggregation - association or composition.

Attributes which types are primitives are the one which are directly related to the instance of an object. On the other hand, aggregations define an object’s relations.

We distinguish the following types of aggregations:

• Association – the object which is a part can exist on its own, even when it’s not a part of relation.
• Composition – the object which is a part that cannot exist without main object. It cannot be shared with any other object. If the main object is removed, then all its compositions as well.

To give you an example, I will use domain that is well known to all of us – software development.

Let’s do something useless

Ok, this one will be trivial, but it needs to be written and, what’s more important – remembered. Doing anything makes sense only if there is a reason to do it. You should not write a line of code just for its own sake. And there are several reasons why you shouldn’t do this. Firstly, there a chance that you really would never need this code. Secondly, you are making an effort that is needed for maintenance. Someone has to take care of this code, someone will read it and so on. And thirdly, useless code makes everyone confused, because “if someone added it, there has to be a reason why he did it”.

But it is not only the case that useless code is not used anywhere. There are situations when you can notice in your application code appearance of methods that, yes, are used, but are only the part of some functional whole. They bring no value on their own except problems.
And those are the “creations” that I would like to write about today.

single responsibility principle – it’s not all

SRP tells us that each class needs to be responsible for only one thing. When creating your own classes/methods, it is also important to remember that our elements need to follow those rules when we are taking context of the application into consideration.

What’s the matter?

You won’t create a method that returns a list of all customer’s invoices if the only thing you need is to get those that aren’t timely paid. Instead of such a method, you should create the one that returns the list of those that you are interested in. The problematic thing is that when you look at the method outside the context, it looks all right. Yet, when you will take context into consideration, then it is obvious the method is not a whole on its own. It is just a part of a bigger whole.

maybe you would like to look at the code?

Let’s look at the example that describes what I just shared.

Let’s imagine that we are working on an application which manages various types of events. Each event has got its own state:

enum EventState {
    CREATED, INITIALIZED, READY_TO_GO, FINALIZED, CANCELED
}

Sometimes it happens that an event somehow is hanging. That’s why once a day applications send notifications about those events to all people who are interested in which events weren’t finalized or canceled:

EventsBatch events = EventRepository.getAll().notFinalized().notCanceled();

if (events.notEmpty()) {
    notyify(events);
}

The code above is quite good, isn’t it? Well, not really. What problems can we expect from such implementation?

First, we can notice violation of SRP. Method’s code is not responsible only for sending a notification when specified conditions will occur. We also defines the events about which user will be notified.

Secondly, let’s imagine that at some moment in time we will add a new functionality and we need to do some kind of operations using exactly the same pool of events. Most of developers would go to EventRepository class first, but there they will see that the method they are looking for does not exist. Do you think that all of them will go over the code to find out whether someone had ever the same need, but instead of creating method he done it inline, as a yet another code instruction? Would you do that? Should we even take such a steps into consideration?
On the other hand, even if a developer will invest his effort into searching there is always a chance that code won’t be found.

And in such situation a developer would create method that doing exactly the same what is done in different place. And it result with next problems that directly comes from violation of DRY. We have two places that need to be refactored no each change (i.e. we are adding another non notifiable state – DUPLICATED). I believe you won’t have a problem imagining how easy it is to forget about any of them.

Also, implementation details can leak to the outside world. We can’t talk about encapsulation and, what is even worse, an external object is the one who takes care of valid state of the object. The truth is that until the batch will be useless events are filtered out. It is in invalid state.

We also have twice as big chances to make a mistake. We need to write more tests, because the same functionality is created in two different places. Even if we find bug in one place, there is no guarantee that we will remember to fix it in another. As a result, correctness of the same functionality in different places can be different. Worse than that, we will be sure that the bug was fixed and even if one day we will find out about an affected place, we won’t even think about an “already fixed” bug.

The last problem is the existence of getAll() method at all. It can happen that this method is never used in application as a result provider. What I mean is that we would not do any additional operation on method’s result, because it is exactly what we need. What if the usage of it ends always with “doing something more” with the result? What does that mean? Well, it means that we have more issues with DRY and SRP that we even thought. There can be many places in the code which generate problems mentioned above.

and in the end…

How many times did you write a method whose results you always had to change? Predicate that was always negated? The method that returns a list that you always have to filter?
If you have to do something with the result of the method execution, if you want to make it usable, then remember that it would be good to read this article once again and think how to refactor your code :)

The consequence of using Test Double

”With great power comes great responsibility”. This quote of Uncle Ben was and is with Peter Parker through all his career as a Spider-Man. It was used to describe how we should handle with difficult situations in our lives and that each choice we make can have an impact not only on ourselves, but also on many other people. I think that quote should be the sentence that each developer will repeat all over again. Just a sec before he/she will starts using Test Double (TD). Because TD gives as the great power which allow us to control everything around tested unit. And yes, it makes everything easier, but as Einstein said: “Everything should be made as simple as possible, but not simpler.“.

Each choice you made while you were deciding whether to use or not TD has impact on tests readability, code coverage, tests value, ease of introducing changes or doing refactoring. Each choice you made has impact on your team mates and probably even on those developers that you don’t even know yet.

That’s why we have to made our choices conscientiously and carefully.

That’s why it is so important to have as wide knowledge about used tools and techniques as possible.

Differences between abstract class and interface

it is obvious, right?

No, it’s not. I have conducted a lot of interviews and very often one of the first questions I used to ask was the one about the differences between interface and abstract class. And still I met a lot of programmers who couldn’t give me the right answer.
In my opinion even a junior programmer should know them, maybe not necessarily with understanding what reasons lie behind, but still ­­­­­- structural differences, specific for particular language (and the same for almost all OOP languages) should be more than known.

What do I find instead? Candidates who were applying for other positions (sometimes even senior ones) who didn’t knew the differences or knew only a few or one.
I know that only the things that we know very well are easy, but those are OO basics and we have to know them to write well-designed code.

What’s the deal with serialization?

Today we’re going to talk about a basic, (but from time to time useful) feature of Java — serialization.
Let’s start with theory. So what is serialization?

To serialize an object means to convert its state to a byte stream so that the byte stream can be reverted back into a copy of the object

[Serializable Objects, Oracle Java Documentation]