Method’s name change a lot

A few days ago I tried to help you with making a decision when you should use constructor and when setter.
In one of the paragraph I wrote:

I don’t like setters. Why? Because those methods in some way break encapsulation.

After sharing this post there were developers that were arguing that setters can be useful.

What can I say?

Constructor or setter?

It goes without saying that every object needs to be created before it can be used. It does not matter whether we are talking about a domain, frameworks, libraries or any other type of the classes. When your code is an Object-Oriented, those classes are only definitions of the objects. You cannot use objects before they are created.

When we are talking about object’s initialization, we often need to think about dependencies. How will you inject them? Will you use the constructor or setter?

Abstract Factory or Factory Method?

Today I would like to tell you about Factory Method Pattern and Abstract Factory Pattern. The purpose of the article is to help you recognize places where one of them should be used.

Performance improvements… or experiments?

The project I’m involved in will face great challenges in the upcoming years. That was the reason why we have decided to focus on improving performance of the application before these improvements become a necessity.
How to increase efficiency? Stability? Responsiveness? How to prepare for future? That was the question that we asked ourselves and our goal was to find the answers.

We prepared the list of the challenges and potential improvements that can help us face them. Then we had to choose the most important items from the list. Each of us had a chance to share their opinion, share their view and suggestions.
During this conversation one of us reminded us about the most important activity that needs to take place before any other - we have to improve the measurement of our application’s performance.

We cannot start to improve, before we’ve got nothing but assumptions!

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?