Re: passing a Factory to a method to create a generic instance
Tom Anderson wrote:
I'm thinking there would be a defined constructor signature that would
be used (as implied in my code). There wouldn't be any need to choose
between options.
How many guest are allowed one room? Two? Three? Four? Five?
public class Room
{
public Room( String guest1, String guest2 ) {}
public Room( String guest1, String guest2, String guest2 ) {}
public Room( String guest1, String guest2, String guest2, String
guest2 ) {}
public Room( String guest1, String guest2, String guest2, String
guest2, String guest2 ) {}
}
Now what if you the hotel very suddenly has to put six or seven in one
room for a large convention? And you've got several subclasses of Room?
And what if next week they want to put 8 in one room?
POJO is good, but any design paradigm can be taken too far. Mutable
objects with getters and setters have their place too, and are very
practical most of the time.
One thing you might want consider:
public ImmutableRoomView
{
public ImmutableRoomView( Room r ) {}
}
Now we have a POJO object that uses our bean as builder.
As an aside, does the introduction of generics, and the way they're used
by Class, mean that something along the lines of a constructor interface
would be useful? Before generics, even if had been was a way to require
that all implementations of an interface declared a specified
constructor, there was no way to make use of it - you call a constructor
using an explicit type literal, where polymorphism doesn't come into
play, or via reflection, where there's no type safety anyway. Can we use
I'm not sure. There's no run time type for generics or parameterized
types, so I'm not sure how you'd detect the generic information.
Then a series of getters and setters will configure the class. While
there's other ways to do this (Serializable, for example), assuming
setters seems the easiest way of reading a class from a arbitrary
format. You just assume each data item has a corresponding setter, a
simple 1-to-1 mapping.
Hang on, i thought you were configuring the class through
AssignmentLoadable.load? This sounds like you've gone reflective.
Good point. assignmentLoad() would have access to the class's private
fields. I'm used to thinking about beans and Swing objects.
I know that in correct use, you'll go straight from instantiation to
initialisation, so the period of Room-that-is-not-a-room is vanishingly
small, and no danger can occur. The problem arises when the use is
incorrect, and uninitialised Rooms can escape to unwitting code. In our
discussion of operator overloading, you said "I like to design things
that can't fail" - where failure is completely impossible by design.
That's what i'm trying to get at here.
See the builder example above, and Lew's point about using builder
objects and throwing errors.
If possible, an object should be constructed in a legal state. If not,
you'll have to check for errors at runtime. As long as this is
encapsulated in the class, it's still safe.
public void addGuest( String name ) {
if( number == 0 || floor == 0 || beds ==0 ) {
throw new RuntimeException( "You blew it pal." );
}
// ..
Now you can't add a guest to an uninitialized room.