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 :)