Re: Design/Inheritance Question
Bruce Feist wrote:
Chris Uppal wrote:
....
it suggests that your hierarchy is focussed on
the wrong aspects of a cell. Presumably, for a maze, the /most/
important fact
is its topology -- not the geometrical shape -- so I'd expect the class
hierarchy to follow that.
That makes sense, although I'm frankly not sure how to do that.
Geometric categorization is easy; I have convenient names and concepts
for most of the shapes involved. Topological categorization is more
difficult for me, because each topology for the cell seems independent,
and I don't have language to describe them -- I don't want to end up
with obscure names that I cannot mentally associate with the meanings of
the classes. I suppose I could manufacture meaningful names somehow out
of the connectivity information... tricky.
....
Here's a possible compromise. Define an interface Topology with methods
that return things like lists of neighbors.
Add to the abstract base class for the cells a method:
public abstract Topology getTopology();
For any cell type where there is a single topology that applies, make
the cell class implement Topology, and return itself:
public Topology getTopology(){
return this;
}
For a cell type where you want to use a separate Topology, for example
one shared with some cases of another cell type, have a non-trivial
getTopology method:
public Topology getTopology(){
if(conditions for special case){
return new SomeTopologyClass(parameters);
}else{
return this;
}
}
Within the cell hierarchy, you can vary the extent to which Topology is
merged with cell type or separate, without affecting any other code.
Patricia