New answers tagged

4

Beyond AlexanderBird's answer, I would simply say the following - object orientation is about telling objects to do things for you, not just exposing attributes and getting you to do things with them. So in the above, you're asking object A about it's object B, then asking object B about C, and so on. Just tell object A to do something, and let it delegate ...


6

Short answer: The problem is that the caller needs to traverse (and know the structure of) the entire multi-object data structure in order to access it's leaf node. I think you're confusing things a bit. You're arguing: if A knows about B and that's ok, and B knows about C and that's ok (etc.), then it must be ok for A to know about C. But it's not ...


-1

I have one simple objection against null: It breaks the semantics of your code completely by introducing ambiguity. Oftentimes you expect the result to be of a certain type. This is semantically sound. Say, you asked the database for a user with a certain id, you expect the resut to be of a certain type (=user). But, what if there is no user of that id? ...


0

The central problem of NULL is that it makes system unreliable. In 1980 Tony Hoare in the paper dedicated to his Turing Award wrote: And so, the best of my advice to the originators and designers of ADA has been ignored. …. Do not allow this language in its present state to be used in applications where reliability is critical, i.e., nuclear power ...


2

No, you should definitely not do that. You need to make a decision about where null is acceptable. If it's acceptable for the map to be null, then set it to the argument without checking. If not, throw an exception because the caller fucked up and they need to find that out as soon as possible. Certainly do not set it to some completely random value, like ...


0

It comes down to what being passed a null at this point means and what problems it will cause later. If this method's specification makes it clear that being passed a null is not acceptable then you can justifiably throw a NullPointerException at this time. In this case either change your code above to throw the exception rather than return null or go with ...


0

public void setMyMap(Map<Key, List<Value>> map) { if (map != null) myMap = map; } It will end up also with a null :-). If you don't want to allow nulls be you who throw the runtime exception with an IllegalArgumentException. It's an old problem. What to do with nulls? I prefer to check nulls at business layer or control layer, but ...



Top 50 recent answers are included