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?