Re: Design question - methods calling methods
On 23-05-2010 15:29, Rhino wrote:
Lew<noone@lewscanon.com> wrote in news:hta80e$l5b$1@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