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?