Design question - methods calling methods
in [Java Programming]
|
From: Jeff Higgins on 23 May 2010 16:58 On 5/23/2010 4:32 PM, Rhino wrote: > > Right now, I think I would benefit from the answer to a new mystery. Please start a new thread. > > I do database stuff fairly frequently and mostly use my copy of DB2 as my > database engine. Naturally, I use ResultSets for a lot of this work. I > know that ResultSet is an interface, not a class, but it is rich in > exactly the sorts of methods I need to grab the Strings, integers and > whatnot in the database or to write them to the database. A short time > ago, I was looking at the source for ResultSet and found that not one of > the many methods in that interface are implemented; every single method > seems to be abstract. I see in the JavaDoc that there are a number of > "sub-interfaces" - I'm really not sure what a sub-interface is and how it > is different from a interface and that it has a "super-interface" - > again, I'm not sure what that is! - but the perplexing thing is that I am > not explicitly using the super-interface or any of the sub-interfaces yet > my code still works fine. That kind of thing disorients me; I wonder how > that could possibly be working and why I don't need to change from > ResultSet to a real class or another sub-interface or whatever. My > pragmatic self is capable of just ignoring all of that and saying "It's a > mystery but I'm not going to question it since it obviously works." But > my more idealistic self is bothered that it isn't obvious to me why the > ResultSet works despite its troubling aspects. > > Can you possibly shed some light on what is happening there? > Otherwise this goes on to troll alert.
From: Jeff Higgins on 23 May 2010 18:41 On 5/23/2010 4:58 PM, Jeff Higgins wrote: > On 5/23/2010 4:32 PM, Rhino wrote: > >> >> Right now, I think I would benefit from the answer to a new mystery. > > Please start a new thread. >> >> I do database stuff fairly frequently and mostly use my copy of DB2 as my >> database engine. Naturally, I use ResultSets for a lot of this work. I >> know that ResultSet is an interface, not a class, but it is rich in >> exactly the sorts of methods I need to grab the Strings, integers and >> whatnot in the database or to write them to the database. A short time >> ago, I was looking at the source for ResultSet and found that not one of >> the many methods in that interface are implemented; every single method >> seems to be abstract. I see in the JavaDoc that there are a number of >> "sub-interfaces" - I'm really not sure what a sub-interface is and how it >> is different from a interface and that it has a "super-interface" - >> again, I'm not sure what that is! - but the perplexing thing is that I am >> not explicitly using the super-interface or any of the sub-interfaces yet >> my code still works fine. That kind of thing disorients me; I wonder how >> that could possibly be working and why I don't need to change from >> ResultSet to a real class or another sub-interface or whatever. My >> pragmatic self is capable of just ignoring all of that and saying "It's a >> mystery but I'm not going to question it since it obviously works." But >> my more idealistic self is bothered that it isn't obvious to me why the >> ResultSet works despite its troubling aspects. >> >> Can you possibly shed some light on what is happening there? >> > > Otherwise this goes on to troll alert. > Hal Vaughan?
From: Arne Vajhøj on 23 May 2010 19:15 On 23-05-2010 16:32, Rhino wrote: > I do database stuff fairly frequently and mostly use my copy of DB2 as my > database engine. Naturally, I use ResultSets for a lot of this work. I > know that ResultSet is an interface, not a class, but it is rich in > exactly the sorts of methods I need to grab the Strings, integers and > whatnot in the database or to write them to the database. A short time > ago, I was looking at the source for ResultSet and found that not one of > the many methods in that interface are implemented; The number of methods is completely orthoginal to abstract base class versus interface. Interfaces never has any implementations so no surprise that ResultSet does not have any. Arne
From: Arne Vajhøj on 23 May 2010 19:21 On 23-05-2010 15:29, Rhino wrote: > Lew<noone(a)lewscanon.com> wrote in news:hta80e$l5b$1(a)news.albasani.net: >> Lew wrote: >>>> Are you familiar with the difference between interfaces and classes? >> Rhino wrote: >>> I'm not sure how to answer that. I've read formal definitions of both >>> and have written both and gotten them to run. But even after all the >>> time I've spent writing Java - I started in 1997 but had a 4 year gap >>> that ended a few months back where I wrote no Java at all - I don't >>> feel solid on a lot of the theory. Maybe I'm expecting too much of >>> myself but I feel like I should know instantly and intuitively what >>> the key differences are between classes and interfaces and not have >>> to wrestle with "should I use an interface or class here". >> >> The Java tutorial describes the difference, but doesn't really address >> your question, so I'll take a stab. >> >> Interfaces are pure contract - they describe the signatures of the >> methods that class instances must implement, but may not contain any >> method implementation nor instance members. (It's also usually a bad >> idea to give them 'static' members.) >> >> Classes may contain some implementation, and must be completely >> implemented if not 'abstract'. >> >> A class can implement an interface - that is, it is a subtype of the >> interface that fills in the missing implementation details. >> >> So you can have an interface: >> >> public interface Foo >> { >> public void fooishBehavior(); >> } >> >> Notice the semicolon instead of a method body - no curly braces in the >> method. >> It's a promise that there will be such a method in any class that >> implements >> the interface. >> >> You can have an implementing class: >> >> public class FooImpl implements Foo >> { >> public void fooishBehavior() >> { >> } >> } >> >> The class's claim that it 'implements Foo' requires it to implement >> the 'Foo' methods, or at least be an abstract class. We'll ignore >> abstract classes for you to study on your own. >> > No worries; I've created and used some abstract classes in the past. I > was going to say they seemed quite straightforward but maybe I should > look into them again, just to make sure I'm not failing to consider > important aspects! But I'll do that on my own and post if I have > questions. > > Having already read your note twice, I'm starting to have trouble > distinguishing between an interface that contains an abstract method and > an abstract class that has an abstract method. But I should probably mull > this over a bit more before attempting any followup questions. I don't > think I understand the interface thoroughly yet so no point in muddying > the waters with abstract classes just yet.... An interface never has any implementation so all methods are always abstract - now and in the future. An abstract class will usually have one or more abstract methods and one or more non-abstract methods now or at least in the future, because otherwise it could have been either a non-abstract class or an interface. Another practical difference is that classes can implement many interfaces but can only extend one class (incl. abstract classes). >> Variables have a type - that's what's important. When you use a >> variable of type 'Foo', all you really care about is to use its >> 'fooishBehavior()'. >> > I always tend to think of variables as things like > > String greeting = "Hello"; > > from my COBOL days. But you're using variable where I might say instance, > right? In this case greeting is a variable that contains a reference to an instance/object of class String. > As in this case, where the variable myform is being instantiated: > > Form myForm = new Form(); > > I'm pretty sure you mean the latter because 'myForm' in this case > presumably has some number of behaviours (methods) to do this and that. > Then again, by virtue of being a String, 'fred' has behaviours too, such > as length() and substring(). Hmm, maybe this is a "distinction without a > difference". Exact same situation. Except that "Hello" is string literal that get a bit special treatment. > After all, > > String greeting = "Hello"; > > is equivalent to: > > String greeting = new String("Hello"); Not quite. The last form is wasting an extra object (unless is somehow got optimized away). Arne
From: Arne Vajhøj on 23 May 2010 19:25
On 23-05-2010 14:55, Rhino wrote: > Arne Vajh�j<arne(a)vajhoej.dk> wrote in news:4bf92f34$0$273$14726298 > @news.sunsite.dk: > >> On 22-05-2010 23:14, Patricia Shanahan wrote: >>> Rhino wrote: >>> ... >>>> I probably tend to overbuild a lot of the time anyway, in the sense of >>>> adding functionality that isn't all that likely to be used. My current >>>> thread about the internationalization/localization is proof of that. I >>>> tend to anticipate needs that others aren't sure will ever happen. Not >>>> all the time of course; it's just a tendency, not an obsession ;-) >>> ... >>> >>> I also get tempted to overbuild. When I started programming, there was >>> some justification, because making design changes in a large program was >>> difficult and risky. >>> >>> These days, it is so easy to refactor that there is generally little >>> benefit to adding complexity that is not needed for immediate needs. >>> >>> The exception is designing APIs that will be used in code outside your >>> control. >> >> API's is a problem because you the most optimal refactoring may >> expose an incompatible API. >> >> But I believe that there are also other cases where refactoring >> is not so easy. >> >> One example is the topic of the thread. Internationalizing an >> existing app is not difficult, but it is usually a lot of work. >> >> I18N is a well-known counter-argument to YAGNI. >> >> Arne > > YAGNI? Sorry, I don't know that acronym..... http://en.wikipedia.org/wiki/YAGNI It is a paradigm about waiting to implement something until you really need it because in many cases you waste time developing sophisticated features that will never be used. Arne |