Re: Tired of 100s of stupid Getter/Setter methods
From: Mark 'Kamikaze' Hughes (kamikaze_at_kuoi.asui.uidaho.edu)
Date: 12/31/03
- Next message: Brian Agnew: "ANN: xmltask 1.9"
- Previous message: Andrew Thompson: "Re: Tryed something that might work, but getting compiler errors."
- In reply to: Dimitri Maziuk: "Re: Tired of 100s of stupid Getter/Setter methods"
- Next in thread: Dave Glasser: "Re: Tired of 100s of stupid Getter/Setter methods"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: 31 Dec 2003 18:47:46 GMT
Dimitri Maziuk <dima@127.0.0.1>
wrote on Mon, 29 Dec 2003 21:10:50 +0000 (UTC):
> Mark 'Kamikaze' Hughes sez:
>> If you were implementing swch a class and wanted to only see the
>> relevant methods, you could implement a restricted interface and
>> recommend using a reference to that. That's the correct solution,
>> rather than ignoring the fact that those methods are appropriate to the
>> subclass.
> Yeah, but interface does not hide the other methods of implementing
> class. Stack/Vector may not be a particularly good example of why you
> would want to hide those methods, but sometimes you do want that even
> IRL (in textbooks it comes under "hiding implementation details").
It is a common academic exercise, because academics don't have any
real work to do, so they obsess about mathematical purity. In real
engineering, though, I've never seen a case where subclassing was
appropriate and yet you'd need to disable some methods. That's a code
smell, telling you that you need to refactor a new common superclass.
> Besides, an interface in Java terms means you have to type in the
> code, whereas inheritance lets you inherit the implementation.
> With composition you can reuse the implementation and hide it, too.
Well, of course you have to type in the code, because the
implementation will be totally different. If there's common code, but
they're not subclassing each other, you're almost certainly doing
something wrong. Again, that's a code smell. "Fixing" it by wrapping
some other class up is like patching on your car door with duct tape.
> A typical Java example is type-safe containers: I want a vector of
> strings, not Objects. But you can't override on return value. The
> (arguably) easiest way out is to put Vector inside StringVector and
> write a bunch of one-liner accessors with (String) casts where
> appropriate. Again, composition instead of inheritance.
That's just hiding the fact of casting from the user, but you're still
paying the performance penalty. java.util.Properties has String->String
mappings, on top of the Hashtable implementation, and that works well
enough for its purposes, because people *don't* abuse it. Prior to
generics going in the language, the "right" solution was to make a
template class (with "${TYPE}" as a placeholder) and use sed to generate
your actual classes. They're not going to have a common interface, no
matter what you do. A StringVector cannot take Integer parameters.
They have methods with the same names, but the signatures are totally
different. Inheritance, composition, and interfaces are all wrong for
that case.
Ultimately, though, "type-safe" containers are not necessary. In 6
years of Java development, I've never had problems with putting the
wrong things in a generic container, and I know this, because the act of
casting it when I withdraw it would be a valid safety check. It's just
paranoia from people who don't test their code adequately.
-- Mark Hughes "God, I think. God. He doesn't answer, and I'd be justifiably scared--but not in a panic!--if he did, since I would know it really was Resuna, or a tiny brain tumor, or some boo-boo in my mix of neurotransmitters." -John Barnes
- Next message: Brian Agnew: "ANN: xmltask 1.9"
- Previous message: Andrew Thompson: "Re: Tryed something that might work, but getting compiler errors."
- In reply to: Dimitri Maziuk: "Re: Tired of 100s of stupid Getter/Setter methods"
- Next in thread: Dave Glasser: "Re: Tired of 100s of stupid Getter/Setter methods"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
