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.
Friday, July 15, 2016
Wednesday, July 6, 2016
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:
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?
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?
Subscribe to:
Posts (Atom)