Many parameters and lost information

The less code, the better? The fewer objects, the better? Is it true? As usual, it depends.

There are cases when by adding something more we are adding unnecessary complexity. It happens when we are creating interfaces or other abstractions just because “we may need this additional flexibility in future”. It happens when we forget about YAGNI principle and we are writing code that may make our life easier in case of new requirements that… may never come.

Implementation, behavior and the amount of the code...

Implementation, behavior and the amount of the code... Today is the right time for another code-related question that I’d like to ask.
Take a look at these methods:

refactoring.setState(IN_PROGRESS);

refactoring.setState(VERIFIED);

refactoring.setState(DONE);

To make everything clear, we can easily assume that each invocation is done in a different place and after different activities have been completed.
There is nothing exciting in this code and probably you saw something similar in your code bases many times. Nothing complicated. We are just changing the state of the object.

So, now’s the time for the question: what’s wrong with this code?

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?

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.

Overriding - let's check how it works

what is method overriding?

Method overriding is a concept based on polymorphism which allows us to create a method with the same signature as in parent class to extend or change its behaviour. Let’s take a look at the definition:

Method overriding - allows a subclass or child class to provide a specific implementation of a method that is already provided by one of its superclasses or parent classes. The implementation in the subclass overrides the implementation in the superclass by providing a method that has same name, same parameters or signature, and same return type as the method in the parent class.

[Wikipedia - Method overriding]

Today we will check what is possible to override and what's not. I will also try to explain why it is so.