I think it would be an advantage because a single row can be shared by many tables
Since you're trying to model the "objects" within a database of some sort, I can't think of any reason for sharing "rows" among tables. Doesn't that violate the relational normal form tenet that data should not be repeated. Consider two tables (same schema), A and B with the same "row". The sameness here refers to their value semantics. If the row component has a getParent() operation; invoking that on the row in both should return different parents. Or consider this (lifecycle mgmt):
I delete table A. What happens to the row reference in table B ? Do you want it to continue existing ?
Let's turn our attention to your design:
AbstractRow AbstractTable
Row1 Row2 Table1 Table2
A row within a table have a somewhat "shaky" concept of rowid (Think: ordinal). By using ArrayList, you are somewhat depending on that notion for the relationship between a table and a row. (NOTE: Have you considered indexes yet ?)
In the row-column relation, you are depending on a Map functionality which is key-based rather than ordinal based.
Thus behaviour-wise; they are *NOT* the same and collapsing them under one AbstractComposite interface is misleading (I hesitate to say wrong because I am no expert).
Pho
[ February 21, 2002: Message edited by: Pho Tek ]