The idea of encapsulation and loose coupling is that you can change the implementation of the object without affecting how it is perceived by other code via its interface.
Stan Belen wrote:. . . this is a legacy DTO.
So, suppose it's used in a lot of places. . . .
Of course: Junilu said it long before I did.
Junilu Lacar wrote:. . . Why isn't the design such that we can just write this:
That looks like a Map of some sort. Please consider whether you can design such a Map.
Stan Belen wrote: . . . A Person's address is stored as one of the attributes . . .
Decide how many attributes are essential, remembering some People lack some attributes, LandLinePhoneNumber being a common one.
might be null might not be null but it might not contain an address might not be null and it might contain an address
I am afraid, that looks wrong in two ways. That method should be called on the object and should therefore not need the Person parameter. What you wrote could readily be converted to a static method, which makes me suspicious about it.
. . .. . .
That's a pleasure
Maris Lakss wrote:Thanks a lot . . .
That line is very error‑prone; it is possible to get two double values which should represent the same result, but where the == operator returns false.
Since each label after case has to be a compile‑time constant or an enum element (Java® Language Specification (=JLS) link), you still can't express ranges, and you can't use a double. You can write. . . but if anybody can think of worse code than that. i would like to see it.
Tim Holloway wrote:. . . switch . . . but I think that this sort of range-checking is still beyond it. . . .
felix bello wrote:. . . done, it's better?