http://qs321.pair.com?node_id=110111


in reply to OO vs. global variables...

Now, one thing I'm gagging on (and this may just be unfamiliarity with the process) is should every object have a pointer to the Board? I mean, should the Point know who its Board is, so to speak?

Yes. A Point needs to know who its Board is so that it can delegate certain questions/actions to its Board.

Having a contained object delegate questions about "location" and "neighbors" to its container is a frequent pattern in OO-land. It usually leads to smaller (and more flexible) class definitions for the contained objects.

Try approaching the problem by way of the question "Which is a more appropriate place to implement this behavior: Board, or Cell?"

Replies are listed 'Best First'.
Re: (dws)Re: OO vs. global variables...
by dragonchild (Archbishop) on Sep 04, 2001 at 22:16 UTC
    So, in the Point class, you'd have a function that sorta looks like: 
    package Point;
# Stuff here...
sub isNextTo {
    my $self = shift;
    my $newPoint = shift;

    return $self->{PARENT}->Point_isNextTo($self, $newPoint);
}
# Stuff here...

    [download]
    I suppose that would make sense, as a Point should not know all about the intricacies of Board layout. For example, I can think of several games (Risk comes to mind) where two Points would be next to one another, but there is no algorithmic way of determining that. So, I suppose the Board should determine next-to-ness.

    *frowns* Does that mean that the Board should be able to dip into the Point's inner workings and get its X and Y coordinates? How would this work without using an accessor function?

    ------
    We are the carpenters and bricklayers of the Information Age.

    Vote paco for President!

[reply]
[d/l]
      You've got the general idea. Board can answer any next-to-ness question for a given Point. Consider this alternative to your fragment: 
        # determine if I am next to aPoint
  sub isNextTo {
      my $self = shift;
      my $aPoint = shift;
      my @neighbors = $self->{Board}->neighborsOf($self);
      return 0 != grep { $aPoint == $_ } @neighbors;
  }

      [download]
      Does that mean that the Board should be able to dip into the Point's inner workings and get its X and Y coordinates?

      The word "Point" carries some baggage (but then so do some alternatives, like "Square"). Let's reframe the question by using "Cell".

      Why should a Cell know its X and Y coordinates? Clearly, somebody needs to know them, but why Cell and not Board? (You might have good reasons to go one way and not the other, but this is a good question to ask yourself before deciding.)

[reply]
[d/l]
        Uhhh... I'd just assumed that because a Point has a location, the Point would know its location. But, thinking about it, it doesn't have to, does it? A point is essentially a state-less object. Any point should be able to be picked up and moved to another spot on the board and no changes need be made (from the Point's point of view, so to speak.) It would be the Board's responsability to make sure that the Points are all working together, and that would include things like layout and the like. Ohhhh.

        Hrmmm... I think I like that thinking methodology. I'd started applying it to some of the application, but hadn't realized just how pervasive a paradigm-shift it really way.

        ------
        We are the carpenters and bricklayers of the Information Age.

        Vote paco for President!

[reply]

In Section Seekers of Perl Wisdom