Design question - methods calling methods

[Jeff Higgins]

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.

 

[Jeff Higgins]

Please start a new thread.

Otherwise this goes on to troll alert.

Hal Vaughan?

 

[Arne Vajhøj]

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

 

[Arne Vajhøj]

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

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

 

[Arne Vajhøj]

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

 

[Arne Vajhøj]

Honestly, I think you're being just a little too rigid now.

I was trying to get across the idea that, at first glance, Map<String,
Locale> sorted Locales = new SortedMap<String, Locale>() might be
something I would CONSIDER writing to address the suggestion that was
made to me. I was trying to get across the idea that these statements all
start to look alike and interchangeable at some point, at least to me. I
know that this is not actually the case but it SEEMS like it sometimes.
Fundamentally, I'm just expressing frustration with myself that it isn't
more intuitive by now which of these statements is the one to use and
which ones don't even make sense.

I know (now) that the statement in question wouldn't actually compile or
make sense and I didn't actually try to compile it anywhere. It was
strictly a hypothetical and I truly think it is reasonable to toss out a
hypothetical now and again even if it is only to dismiss it very quickly
as the responders rightly did. I will continue to do that - very
sparingly I expect - and do so at my own peril. Maybe some of you will
disgusted with me for doing so and stop responding to me. If so, that's
life. I'll do what penance is needed to get back into everyone's good
graces or move on to some other discussion group if I have to.

The problem with pseudo code outlines is that there are
no well-defined syntax and semantics for it.

So you can not communicate efficiently with other, because
you may think X means one thing, but the readers may
think X means something else.

Java has a well-defined syntax and semantics that makes
it unambiguous for communication. And if there are any
doubt then the compiler and the JLS well help sort it out.

Posting pseudo-code that is very similar to Java is very
very bad, because that quickly changes the topic of
discussion from your real problem to the syntax errors.

Arne

 

[Jeff Higgins]

The problem with pseudo code outlines is that there are
no well-defined syntax and semantics for it.

So you can not communicate efficiently with other, because
you may think X means one thing, but the readers may
think X means something else.

Java has a well-defined syntax and semantics that makes
it unambiguous for communication. And if there are any
doubt then the compiler and the JLS well help sort it out.

Posting pseudo-code that is very similar to Java is very
very bad, because that quickly changes the topic of
discussion from your real problem to the syntax errors.

Thank you.

 

[Lionel]

But no methods > 3 lines is not good either.

public class SomeContainer {
int attribute1;
int attribute2;
bool isAttribute3;

public SomeContainter() {
attribute1 = 0;
attribute2 = 0;
isAttribute3 = false;
}

public void setAttribute1(final int newValue) {
attribute1 = newValue;
}

public void setAttribute2(final int newValue) {
attribute2 = newValue;
}

public void setIsAttribute3(final bool newValue) {
isAttribute3 = newValue;
}

public int getAttribute1() {
return attribute1;
}

public int getAttribute2() {
return attribute2;
}

public int isAttribute3() {
return isAttribute3;
}
}

???

 

[Arne Vajhøj]

public class SomeContainer {
int attribute1;
int attribute2;
bool isAttribute3;

public SomeContainter() {
attribute1 = 0;
attribute2 = 0;
isAttribute3 = false;
}

public void setAttribute1(final int newValue) {
attribute1 = newValue;
}

public void setAttribute2(final int newValue) {
attribute2 = newValue;
}

public void setIsAttribute3(final bool newValue) {
isAttribute3 = newValue;
}

public int getAttribute1() {
return attribute1;
}

public int getAttribute2() {
return attribute2;
}

public int isAttribute3() {
return isAttribute3;
}
}

???

Yes.

It is a very bad application. No logic at all. Due to no
main method, then i can not even be ran.



Arne

 

[Lew]

Arne Vajhøj wrote in
Lionel wrote [a good example of Arne's point]:

public class SomeContainer {
int attribute1;
int attribute2;
bool isAttribute3;

public SomeContainter() {
attribute1 = 0;
attribute2 = 0;
isAttribute3 = false;
}

You don't even need this constructor.

public void setAttribute1(final int newValue) {
attribute1 = newValue;
}

Getters and setters model attributes, not behaviors. Arne's comment applied
to behaviors.

public void setAttribute2(final int newValue) {
attribute2 = newValue;
}

public void setIsAttribute3(final bool newValue) {
isAttribute3 = newValue;
}

public int getAttribute1() {
return attribute1;
}

public int getAttribute2() {
return attribute2;
}

public int isAttribute3() {
return isAttribute3;
}
}
>
???

Exactly, "???". What are you supposed to do with this class?