Ad
  • Custom User Avatar

    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 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.

  • Custom User Avatar

    Not anymore ;-)

  • Default User Avatar

    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).

  • Default User Avatar

    Moreover, if we change one dimension of the Block with a simple setter, the Surface Area and Volume become wrong.

  • Default User Avatar

    The description says "... also a straight double of the same number in num2.", so ...

  • Custom User Avatar

    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.

  • Custom User Avatar

    You're absolutely right :D
    I wrote this just for convenice and it is somehow a bad habbit keeping using string...