Re: Design question - methods calling methods
On 23-05-2010 06:48, Tom Anderson wrote:
On Sun, 23 May 2010, 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 ;-)
This is a universal tendency. Everyone has it to some extent. From what
i remember of the dim depths of time, i had it rather strongly when i
was starting out programming, although it manifested itself in writing
overcomplicated class hierarchies and mad epicyclic structures of
composed objects. Kent Beck once accused me of suffering from 'premature
abstraction'. I think it's common to suffer from it strongly when you
first start thinking about design, and to grow out of it in time.
http://www.ariel.com.au/jokes/The_Evolution_of_a_Programmer.html
I would word it a little bit different: abstraction is good - *IF* it
serves a purpose.
Well,
or to become an architect, architects being the Peter Pans of the
programming world.
:-)
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". But maybe guys
like you and Eric and Tom have to think long and hard about that too.
I really don't know.
It's unusual to be in a situation where there is a real choice between a
class and an interface. When you're deciding the type of a variable, you
ask, as Lew said, "what is the most general type that guarantees the
behaviour i want from this variable". You don't worry about whether that
type is a class or an interface.
When you're designing an inheritance hierarchy to exploit polymorphism,
you can choose to make the root type an interface or an exposed base
class. Like:
public abstract class DataStore {
public abstract Data load(String id);
}
public class RelationalDataStore extends DataStore {
public Data load(String id) {
// code
}
}
vs
public interface DataStore {
public Data load(String id);
}
public class RelationalDataStore implements DataStore {
public Data load(String id) {
// code
}
}
The mainstream modern school of thought is that you should always choose
the interface, so there's no real dilemma there either.
I think that is exaggarating.
Inheriting from abstract base classes is used all over the
Java API.
Joshua Bloch used the word "Prefer" in this context.
Sometimes is do make sense to reuse implementation functionality
(which is what the abstract base class offers).
Quite frequently a compromise is used with both an interface
and an abstract base class. This means that the 95% can
extend and only implement the few methods they need, but
still allow the remaining 5% to implement the interface
with full flexibility.
Arne