Re: passing a Factory to a method to create a generic instance
On Sun, 11 May 2008, Mark Space wrote:
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?
Room.getNumBeds() * Room.getBedSize()!
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?
The one constructor that i want Room to support is one that takes an
IOStream, just like your AssignmentLoadable.load interface. How were you
planning to solve this problem?
I assume that the Room constructor would be responsible for determining
the number of guests and reading their details from the stream.
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
You keep using that word. I do not think it means what you think it means.
object that uses our bean as builder.
I'd call ImmutableRoomView Room and Room RoomBuilder (or RoomSpec - if you
call RoomThinger.build() to get a Room, it's a builder, but if you pass a
RoomThinger to Room's constructor, it's a spec), but there you go.
Anyway, i don't think i argued for immutable rooms. But having public
setters for things like room number and floor seems questionable to me.
Ooh, and if you must pass a variable number of guests in to the
constructor, that's easy:
class Party implements Set<Guest>
class Room {
public Room(Party pty, etc)
}
! Only kidding.
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.
You have the actual Class object, that's how. And you have a generic
guarantee that the Class that's been passed in is something that
implements AssignmentLoadable. That feels like it should be enough, but
i'm not sure.
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.
Nothing a couple of litres of overproof rum can't cure!
The combination of a bean-like, reflectively-configured RoomBuilder/Spec
object and a 'POJO' Room which you make with it, which i now realise is
what you're getting at, sounds like an excellent way forward to me.
Although it still doesn't solve our original problem of refactoring Room-
and Guest-loading code into one method. Unless the Room/GuestBuilder is
instantiated reflectively too? And the code for configuring them works
equally well with Guests and Rooms? Could be done, i guess. I still think
good old fashioned polymorphism is simpler, though.
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.
No - but you can still write a program which tries to do so. I want to
make that statically impossible.
Which is why i'm completely down with the builder idea.
Although i think we might still need a BuilderFactory.
And i definitely need at least a litre of overproof rum.
tom
--
Argumentative and pedantic, oh, yes. Although it's properly called
"correct" -- Huge