Re: Design question - methods calling methods
Lew wrote:
Are you familiar with the difference between interfaces and classes?
....
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.
Rhino wrote:
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 MUST NOT have any implementation of its methods. It's pure type.
An abstract class MAY have implementation for any or all of its methods. It's
type with some implementation.
A type may inherit (extend or implement) any number of interfaces. A class
may only extend from one class.
Lew wrote:
The key is to think in terms of types, not classes. Interfaces are
pure expressions of type, and classes express a way for the type to do
something actual.
Rhino wrote:
So, because Set is an interface, all of its implementors, including
HashSet, LinkedHashSet and TreeSet, need to implement all of its (non-
abstract) methods.
There are no non-abstract methods in an interface.
But HashSet can implement the contains() method
differently than TreeSet does if that seems advisable.
Correct.
Rhino wrote:
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?
No.
An instance is the object itself. A variable is a pointer to the instance.
As in this case, where the variable myform is being instantiated:
Form myForm = new Form();
No, the variable is being initialized. The instance is being instantiated.
("Instance", "instantiate" - see the connection?)
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.
No, the instance has behaviors. The variable only gives you access to invoke
those behaviors.
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". After all,
I don't know what you're talking about here. Again, the variable does not
have behaviors, it only gives you (possibly limited) access to those behaviors
by pointing to the object that actually does have the behaviors (and possibly
others to which the variable does not give access).
String greeting = "Hello";
is equivalent to:
String greeting = new String("Hello");
No, those are not at all equivalent.
Or, to use an example from the API:
Set<String> mySet = new TreeSet<String>();
Would you consider that a parallel example? In other words, in your
example, was Foo an interface while FooImpl was a class?
Did you actually *read* the sample code I provided for 'Foo' and 'FooImpl'?
The answer is there:
So you can have an interface:
public interface Foo
{
public void fooishBehavior();
}
....
You can have an implementing class:
public class FooImpl implements Foo
{
public void fooishBehavior()
{
}
}
Tch, tch.
Rhino wrote:
Since I'm not 100% sure whether you mean Foo to be an interface or a
class, let me just ask if you're saying that your example is logically
I really don't get how you aren't. I get the feeling you aren't paying attention.
equivalent to changing:
Set<String> mySet = new TreeSet<String>();
to
Set<String> mySet = new HashSet<String>();
In my example, you may have decided that the performance benefits of the
HashSet outweigh the fact that your data is in alphabetical order within
the TreeSet.
What performance benefits?
Given that you need results in sorted order, you are nearly certain not to
have any. Even without that, what performance benefits?
Performance is never an argument that wins over logical correctness.
"I can give you wrong answers in half the time of correct ones!"
--
Lew