An example from a book is method NewFloorRequest in the right class

[Tony Johansson]

Hello!

Below is an example from a book. The books is position method
NewFloorRequest in class Person.
What is your opinion about that in this example ?
How should I think here ? If I think who is pushing the button then it's
the Person and so it should be in class Person.
I also mean that it belong more logically to class Elevator.

Can somebody give me a guideline how I should think when trying to find a
suitable class for method
NewFloorRequest ?

using System;

class Elevator
{
private int currentFloor = 1;
private int requestedFloor = 0;
private totalFloorsTraveled = 0;
private Person passenger;

public void LoadPassenger()
{
passenger = new Person();
}

public void InitiateNewFloorRequest()
{
requestedFloor = passenger.NewFloorRequest();
Console.WriteLine("Departing floor: " + currentFloor);
+ " Traveling to floor: " + requestedFloor);
totalFloorsTraveled = totalFloorsTraveled + Math.Abs(currentFloor -
requestedFloor );
currentFloor = requestedFloor;
}

public void ReportStatistic()
{
Console.WriteLine("Total floors traveled: " + totalFloorsTraveled );
}
}

class Person
{
private System.Random randomNumberGenerator;

public Person()
{
randomNumberGenerator = new System.Random();
}

public int NewFloorRequest()
{
return randomNumberGenerator.Next(1,30);
}
}

class Building
{
private static Elevator elevatorA;

public static void Main()
{
elevatorA = new Elevator();
elevatorA.LoadPassenger();
elevatorA.InitiateNewFloorRequest();
elevatorA.InitiateNewFloorRequest();
elevatorA.InitiateNewFloorRequest();
elevatorA.InitiateNewFloorRequest();
elevatorA.InitiateNewFloorRequest();
elevatorA.ReportStatistic();
}
}

//Tony

 

[Andrew Poelstra]

Hello!

Below is an example from a book. The books is position method
NewFloorRequest in class Person.
What is your opinion about that in this example ?
How should I think here ? If I think who is pushing the button then it's
the Person and so it should be in class Person.
I also mean that it belong more logically to class Elevator.

Can somebody give me a guideline how I should think when trying to find a
suitable class for method
NewFloorRequest ?

using System;

class Elevator
{
private int currentFloor = 1;
private int requestedFloor = 0;
private totalFloorsTraveled = 0;
private Person passenger;

public void LoadPassenger()
{
passenger = new Person();
}

I stopped reading here. Not only can this elevator only hold
one person, that person must be of the elevator's own creation?

Perhaps if this elevator is in a haunted house this would
be good design..

 

[Andrew Poelstra]

I stopped reading here. Not only can this elevator only hold
one person, that person must be of the elevator's own creation?

Perhaps if this elevator is in a haunted house this would
be good design..

I should have clarified as to how this design could be improved.
Firstly, the Elevator class should have a collection of people,
not just one person.

Then, you would have functions to load and unload people,
associate requested floors with people (and this function would
then create a reasonably ordered sequence of floors to
visit), but not to create new people out of thin air.

 

[Jesse Houwing]

* Andrew Poelstra wrote, On 19-1-2010 23:49:

I should have clarified as to how this design could be improved.
Firstly, the Elevator class should have a collection of people,
not just one person.

Then, you would have functions to load and unload people,
associate requested floors with people (and this function would
then create a reasonably ordered sequence of floors to
visit), but not to create new people out of thin air.

If you take the elevator idea (it is a nice concept), then you don't
need to maintain which person wants to go where. Just that a person
wants to go there. And then the elevator can notify each person that it
has arrived on a certain floor.

My guess is that this is a sample that will grow over time.

I think it is correct to ask the person class where it wants to go, only
the person can truly know this. Though the current implementation seems
to have combined the Lift-boy and the elevator into one class. I've
never had an elevator ask me where to go, I always have to push the
buttons myself.

It is a common model to create a class for your actual actor (in this
case the Person) and to put methods in that class which represent the
actions the actor can carry out, or to access the information the actor
might know.

It isn't the best example in its current form though...

 

[Peter Duniho]

Hello!

Below is an example from a book. The books is position method
NewFloorRequest in class Person.
What is your opinion about that in this example ?

I think the main thing is to keep in mind that the example is obviously
contrived. That is, while it provides a concrete, real-world example to
help you follow along whatever the book is trying to illustrate, the
example is necessarily limited in how realistic it may be, specifically
because of the purpose of illustration.

As for Andrew's comments about whether an elevator should create a
Person instance, or contain more than one, I disagree:

– The Person class does not necessarily need to be thought of
literally as a _person_, but rather can be considered to be the
elevator's own representation of (or proxy for) an actual person. In
fact, given that the Person class most likely does not have all of the
other behaviors one might find in a person (breathing, eating, walking,
farting, etc.), it seems obvious to me that the Person class is just a
proxy.

– The elevator does not necessarily need to maintain more than one
person. The elevators we all normally use these days of course handle
more than one person. But there are still lots of elevators out there
that can carry only a single person at a time. In this code example, it
apparently is modeling one of those elevators.

The main thing is to not get too hung up on how precisely this code
example models one's preconceptions about an "elevator", "person", and
the relationship between the two. Instead, focus on what the author of
the book is trying to illustrate in terms of how to go about designing
and using OO types.

That said…

How should I think here ? If I think who is pushing the button then it's
the Person and so it should be in class Person.
I also mean that it belong more logically to class Elevator.

I would tend to agree with your observation. The code as written has a
polling characteristic to it. That is, the Elevator class is basically
repeatedly asking the Person class for a new floor choice. But of
course, that's inefficient and not at all how the real world works.

Assuming _only_ an Elevator and Person class, I would have the Elevator
class include a method by which a Person instance can request a new
floor. That's more of an event- or interrupt-driven design, which is
more efficient, and also more closely models the real world.

Of course, note my reply in your previous question about this
Elevator/Person design, where I pointed out that in reality you'd
probably have a third "controller" class, which receives the passenger
requests: both when calling an elevator, as well as requesting a
specific floor once aboard the elevator.

But within the context of this specific example, I'd agree that at the
very least, having the Person class "interrupt" the Elevator class,
rather than having the Elevator class "poll" the Person class makes more
sense.

But even there, note that my concern is mainly one of modeling and
efficiency. Given that the code example is clearly contrived to begin
with, I would not be too terribly concerned with minor details such as
that. Just adjust your own mental model of the elevator/person
relationship to match the code, and then base your understanding of the
examples given in the book on that.

Either that, or just give up on the book. But if you're going to
keep working with the book, there's no sense in spending a lot of time
fighting the book. Just recognize when you're making personal
simplifications or adjustments to accommodate the book's examples, and
then take from the examples whatever it is the author is trying to
illustrate at that moment.

Pay attention to what the author is trying to tell you, but do pay
attention to your own intuition.

Can somebody give me a guideline how I should think when trying to find a
suitable class for method
NewFloorRequest ?

Ideally, class design involves a few specific priorities:

– Realism. The design should provide an intuitive model of
_something_. Many classes model something that's itself abstract, but
the modeling should still fit a reasonable person's own mental view of
whatever's being modeled.

– Simplicity. Classes should do a few things extremely well, rather
than trying to do a large number of things poorly. I mean, this is of
course good advice for practically anything or anyone trying to
accomplish some goal. But it's an especially important element in class
design.

– Efficiency. IMHO, this almost always goes hand-in-hand with
simplicity. But regardless, the point is that the fewer connections
that exist between classes, the fewer operations that need to occur to
accomplish a goal, and the less specific state that needs to be
maintained, the better.

There may be some other valid points people would include, but I think
that a) the above is an excellent basis with which to start, and b)
sticking to a small number of priorities makes it simpler to manage
every priority during class design and to evaluate success during that
process.

For the same reasons it's good to keep each class simple, it's good to
keep the overall process simple too. The human brain simply isn't that
good at juggling a large number of different things at once, and so the
better your development process is at working with the strengths of your
own human brain and not fighting its limitations, the more successful
you'll be.

Pete

 

[Peter Duniho]

If you take the elevator idea (it is a nice concept), then you don't
need to maintain which person wants to go where. Just that a person
wants to go there. And then the elevator can notify each person that it
has arrived on a certain floor.

How can it notify each Person instance if it doesn't keep track of each
Person instance? _Some_ code has to track the instances, and it could
just as easily be the elevator. Otherwise, each Person instance needs
to repeatedly poll the elevator to see if it's at the correct floor yet.

I agree with your sentiment to an extent. But the class _does_ retain
the reference to a person, so arguing that maintaining a single Person
instance is okay while maintaining multiple Person instances is not
cannot be done on _that_ basis.

Note my other reply: I think it's fine to have a single Person retained;
I also agree with you if you're suggesting that the class doesn't
necessarily need to know _any_ Person instance…but that's obviously not
how this Elevator logic has been designed.

For one, because it's using polling, it has to _ask_ each passenger to
choose a floor, and it can't do that unless it knows what Person
instances are aboard the elevator. For another, perhaps it tracks the
Person instances so it knows whether the current passenger load is
overweight or not. And of course, someone has to tell each
passenger that the elevator has arrived at a new floor. The elevator
may not track each passenger per floor, but it still needs _some_ way of
advertising that it's time for people to get off.

My guess is that this is a sample that will grow over time.

I think it is correct to ask the person class where it wants to go, only
the person can truly know this. Though the current implementation seems
to have combined the Lift-boy and the elevator into one class. I've
never had an elevator ask me where to go, I always have to push the
buttons myself.

Right. The design is valid, but doesn't do a very good job of modeling
current elevator design. Elevators today don't generally poll the
passengers.

It is a common model to create a class for your actual actor (in this
case the Person) and to put methods in that class which represent the
actions the actor can carry out, or to access the information the actor
might know.

In other words, to model the actor itself. I definitely agree with
that.

Pete

 

[Jesse Houwing]

* Peter Duniho wrote, On 20-1-2010 0:24:

How can it notify each Person instance if it doesn't keep track of each
Person instance? _Some_ code has to track the instances, and it could
just as easily be the elevator. Otherwise, each Person instance needs to
repeatedly poll the elevator to see if it's at the correct floor yet.

I didn't mean that the elevator would not contain a list of persons that
are in the elevator. But it would seem illogical to maintain a
collection of <person requester, int floor>. A person would know when to
get out when it's notified that the elevator has arrived on a certain floor.

I agree with your sentiment to an extent. But the class _does_ retain
the reference to a person, so arguing that maintaining a single Person
instance is okay while maintaining multiple Person instances is not
cannot be done on _that_ basis.

It was the sentence "associate requested floors with people" that
triggered my response. There is no apparent need to keep track of who
asked to go where.

So it seems we agree in full .

(Though a good lift-boy would know who asked to go where and say: "Mr
Duniho, we've arrived on your floor, have a good day sir!" ) and would
just ignore the other passengers.

I guess the Lift-boy would model very nicely as a controller class.

 

[Paul Shapiro]

* Peter Duniho wrote, On 20-1-2010 0:24:

I didn't mean that the elevator would not contain a list of persons that
are in the elevator. But it would seem illogical to maintain a collection
of <person requester, int floor>. A person would know when to get out when
it's notified that the elevator has arrived on a certain floor.



It was the sentence "associate requested floors with people" that
triggered my response. There is no apparent need to keep track of who
asked to go where.

So it seems we agree in full .

(Though a good lift-boy would know who asked to go where and say: "Mr
Duniho, we've arrived on your floor, have a good day sir!" ) and would
just ignore the other passengers.

I guess the Lift-boy would model very nicely as a controller class.

In a data model I could see 3 objects:
Elevator(elevatorID, location, currentFloor, directionOfTravel, etc.)
Person(personID, lastName, firstName, etc.)
ElevatorPassenger(elevatorID, personID, requestedFloor)

In the normal case the elevator doesn't care about (or know about)
individual people, but just about travel requests. So instead of Person and
ElevatorPassenger we might have:
ElevatorFloor(elevatorID, floorNameOrNumber, hasStopRequested,
hasHallRequestUp, hasHallRequestDown),
where hasStopRequested tracks a stop requested by an onboard passenger and
the 2 hasHallRequests track status of the up and down buttons a prospective
passenger at a hall landing can push to ask to be picked up. If the hall has
a single elevator request button, then those 3 attributes would be replaced
by a single hasStopRequest since there's no longer any knowledge about the
requested direction of travel.

 

[Arne Vajhøj]

In a data model I could see 3 objects:
Elevator(elevatorID, location, currentFloor, directionOfTravel, etc.)
Person(personID, lastName, firstName, etc.)
ElevatorPassenger(elevatorID, personID, requestedFloor)

That structure looks more as an "in database" data structure
than as an "in memory" data structure.

Arne