• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

OO in terms of Java

 
Bartender
Posts: 10780
71
Hibernate Eclipse IDE Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Campbell Ritchie wrote:How much evidence is there for Odersky Spoon and Venners to argue that so many implementations of equals are wrong?


Well, they were quoting Vaziri, Mandana, Frank Tip, Stephen Fink, and Julian Dolby. “Declarative Object Identity Using Relation Types." In Proc. ECOOP 2007, pages 54–78 - so perhaps the question is best directed at them.

I also reckon it's a good warning - equals() is not as simple as you think.

And you can get as much heat rather than light about whether to throw NPE or a different Exception. Nearly as good as spaces vs tabs for indenting


I don't think I was saying "don't throw NPE". I'm saying "decide what you want to do with null before you write a compareTo() implementation".

Sorry if it wasn't clear.

Winston
 
Marshal
Posts: 79179
377
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Winston Gotkowski wrote:. . . Vaziri, Mandana, Frank Tip, Stephen Fink, and Julian Dolby. “Declarative Object Identity Using Relation Types." In Proc. ECOOP 2007, pages 54–78 . . .

Thank you
Haven't had long enough to read that paper, but I am not 100% convinced they haven't been exaggerated in quotation.

I don't think I was saying "don't throw NPE". . . .

You weren't. But I just remembered the discussions we had here about which Exception to throw for nulls.

I personally think that the response to nulls should be shoot the exception off first, ask questions afterwards
 
Bartender
Posts: 1464
32
Netbeans IDE C++ Java Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Campbell Ritchie wrote:And you can get as much heat rather than light about whether to throw NPE or a different Exception.



I'm the one who asked for this advice, but I'll also weigh-in on this specific point: I don't much care which exception a programmer chooses, provided that programmer is consistent about their choice. You guys may be doing work where exceptions don't mean the end of the world, but my programs that throw exceptions do so when something that should never happen has happened. To me, the particular exception is pretty much irrelevant. I just need to know why it was thrown, so I can make sure it never gets thrown again.

That article on "tell, don't ask," is a good one, Winston. Thanks for the link.
 
Winston Gutkowski
Bartender
Posts: 10780
71
Hibernate Eclipse IDE Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Stevens Miller wrote:I don't much care which exception a programmer chooses, provided that programmer is consistent about their choice...


Me neither. My main argument about NPE is that you shouldn't leave it up to the JVM to throw, because then it becomes an effect and not a cause - but how you go about it and whether you throw NPE or something else I really don't have any strong feelings about.

My normal rule of thumb is that if I can naturally call a method on the "possibly null" object in the first line of a method, then I let nature take its course; otherwise I check for it explicitly - and in that case I throw an Exception with an explicit message. But whether it's NPE or IAE or even something like IllegalStateException, I really don't care too much.

Winston
 
Stevens Miller
Bartender
Posts: 1464
32
Netbeans IDE C++ Java Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Winston Gutkowski wrote:My normal rule of thumb is that if I can naturally call a method on the "possibly null" object in the first line of a method, then I let nature take its course; otherwise I check for it explicitly - and in that case I throw an Exception with an explicit message. But whether it's NPE or IAE or even something like IllegalStateException, I really don't care too much.



Same here.
 
Stevens Miller
Bartender
Posts: 1464
32
Netbeans IDE C++ Java Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Continuing in this (more or less) related sub-thread: how do you guys feel about The Law of Demeter?
 
Winston Gutkowski
Bartender
Posts: 10780
71
Hibernate Eclipse IDE Ubuntu
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Stevens Miller wrote:Continuing in this (more or less) related sub-thread: how do you guys feel about The Law of Demeter?


Speaking personally, I don't actually think about it very much because it seems to be a natural by-product of loose coupling - but which is the chicken and which the egg I couldn't really tell you.

Winston
 
Stevens Miller
Bartender
Posts: 1464
32
Netbeans IDE C++ Java Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Winston Gutkowski wrote:I don't actually think about it very much because it seems to be a natural by-product of loose coupling...


That's actually a very helpful reply, Winston, as it focuses on the "why" of LoD, rather than the "what." I find it's fairly easy to dig up good rules of thumb about OO coding (though a single source with all of them would still be nice). In a lot of cases, the reason the rule is a good one is obvious or apparent after a moment's thought. LSP is easy to comprehend, once you start thinking about overriding methods in ways that defeat expectations based on the behavior of superclasses, for example. Tell-Don't-Ask took me a little longer to get a grip on, and that article you linked explains it in terms of LoD, which I've encountered many times elsewhere. Some of those encounters take it as gospel, but some point out that rigid obedience to LoD can lead to the proliferation of wrappers for, ultimately, no very good reason. So the question really becomes, for me, what purpose does LoD serve? The preservation of loose coupling is a good answer to that question, and one that, to me, needs no further justification. Since it's the justification that makes a rule of thumb worth knowing, that's really what I was after.
 
Winston Gutkowski
Bartender
Posts: 10780
71
Hibernate Eclipse IDE Ubuntu
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Stevens Miller wrote:Some of those encounters take it as gospel, but some point out that rigid obedience to LoD can lead to the proliferation of wrappers for, ultimately, no very good reason. So the question really becomes, for me, what purpose does LoD serve? The preservation of loose coupling is a good answer to that question, and one that, to me, needs no further justification.


I've never really thought about "Tell, don't ask" in terms of LoD. The thing I like about it is that it deals with responsibility - the "S" part of "SOLID" if you like - and also encapsulation (the "what not how").

As soon as I start creating a moderately complex class, my assumption is that there will be a business reason for it, presumably determined by some BP model; so the "business" (no pun intended) of my class's API is to reflect that model, not to offer anyone who uses it a peek into it's inner workings. It's MY class's responsibility to enact a business process, and to make sure that it gets done properly.

Take a Seat on an aircraft. It seems highly likely that someone will want to book that seat, so you write a book() method for it. But then you start thinking (always a problem): What if it's already booked? So you write an isBooked() method. But what if I try to book it at the same time as someone else? So you add a synchronized setBooked() method... Do you see where this is going? You're designing the class from the outside, instead of letting IT handle the things it's responsible for. Seat.book() should do one of two things:
1. Return a reservation.
2. Tell you that (and possibly why) it can't.
End of story. And the only time you should worry about how it does that is when you're implementing the class.

IMO, it's a pity that we teach newbies about getters and setters so quickly, because to my mind they really only belong in very low-level objects.

Winston
reply
    Bookmark Topic Watch Topic
  • New Topic