It's a typical immutablevalue object, the fields are effectively final and compared to object instantiation overhead those simple calculations are negligible regarding impact on performance. Indeed, the fields could have been made final and the equals() and hashCode() methods could have been overridden.
Beware of superfluous POJO usage where objects degrade to simple data containers with fields and getters + setters for all of those. This is not OOP.
Well, the description doesn't ask for setters, that's why I would even suggest to mark the instance variables as final, and thus make the whole class thread-safe. Unless, of course, mutability is a strict requirement.
If you really care about the very last bit of performance, you could even consider to do the computation once and only once (see my solution).
Maybe because it's not a valid solution regarding the task? It is not checking whether the double is of the same digits as the triple. Unfortunately there are no hardcoded test cases for this and it's quite rare that it appears in a random test case.
It's a typical immutable value object, the fields are effectively final and compared to object instantiation overhead those simple calculations are negligible regarding impact on performance. Indeed, the fields could have been made
finaland theequals()andhashCode()methods could have been overridden.Beware of superfluous POJO usage where objects degrade to simple data containers with fields and getters + setters for all of those. This is not OOP.
Not anymore ;-)
Well, the description doesn't ask for setters, that's why I would even suggest to mark the instance variables as
final, and thus make the whole class thread-safe. Unless, of course, mutability is a strict requirement.If you really care about the very last bit of performance, you could even consider to do the computation once and only once (see my solution).
Moreover, if we change one dimension of the Block with a simple setter, the Surface Area and Volume become wrong.
The description says "... also a straight double of the same number in num2.", so ...
Maybe because it's not a valid solution regarding the task? It is not checking whether the double is of the same digits as the triple. Unfortunately there are no hardcoded test cases for this and it's quite rare that it appears in a random test case.
it's not enough tests. And it would be nice to add
a few examples in description
Very interesting kata!
Why didn't I think of that?
You're absolutely right :D
I wrote this just for convenice and it is somehow a bad habbit keeping using string...
With frequent use concatenation, it would be better to use class StringBuilder.
it's really cool!
This comment is hidden because it contains spoiler information about the solution