in reply to (dws)Re: OO vs. global variables...
in thread OO vs. global variables...

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!

Replies are listed 'Best First'.
Re: Re: (dws)Re: OO vs. global variables...
by dws (Chancellor) on Sep 04, 2001 at 22:40 UTC
    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