|Think about Loose Coupling|
Re: OO vs. global variables...by Masem (Monsignor)
|on Sep 04, 2001 at 21:50 UTC||Need Help??|
I think what seems tricky is how a Point is going to know it's an edge point in a typical OO fashion, as you're finding out, you're trying to make objects work uphill as well as down. This typically doesn't work well.
There's three possible solutions that I can think of, two requiring massive code changes in Board and other parts of the code, and one that requires Point to be changed. Let me do that one first:
If this were C++, I would say one possible solution is to use templates (Pardon any syntax, I know what I mean, but haven't written C++ in years :-), and I just want to show the idea here...)
What comes about here is that implicitely, you've passed the board size to the point class (which is specific to the board size), so the point doesn't know what Board it is part of, but can work out edge information from this. Can this be done in Perl? Sure, at the cost of two extra int's per point. It's not as 'invisible' as the C++ template method, but then allows you to check edge states without having a Board object to worry about.
A second way would be to avoid having points know how to check for edges, and instead have those functions built into the Board class. It makes, from an object pov, more sense to have it this way, though from your description, it sounds like you'd have to modify code throughout to make this work.
Finally, you could create a small BoardInfo class that only contains just enough info about the board itself (size, for example) that could be passed around to other objects without passing the entire Board object. The Board object itself could hold on to one copy of this to replace it's own versions of size and other details. But again, this is sort of getting away from a good OOP solution, since Points would need to know the BoardInfo to determine if they are edge points.
(A fourth solution, icky but doable, is to create subclasses of points, MiddlePoint, EdgePoint, and CornerPoint, that would be determined by the Board object at creation time, and would immediately know what their state is. But that seems like lots of extra classes...)
IMO, 2 is the *best* way to go, but 1 is the most adaptable if you are already though hours of coding.