This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
A table contains 0 to more rows. I use an Arraylist to represent table and Maps to represent row. ArrayList and Map are two different entities. After reading the composition pattern, I think it would make sense. AbstractComponent is an interface for both row and table, but I am a little reluctant to treat row and table the same. Would you provide the advantages of implementing composition pattern over my current design. Thanks for your input
The composition relationship should be used in cases where a class A directly manages the lifecycle of class B. Thus you get:
What that means is that B cannot exist without the existence of A. In your case, if we were to treat the row of data:
as a Value object in a database, there is nothing preventing that row from existing in another table. So composition is not so suitable. [ February 18, 2002: Message edited by: Pho Tek ]
Joined: Apr 20, 2001
Pho I don't recall that AbstractComposite has to maintain life cycle of the leaves. there is nothing preventing that row from existing in another table. So composition is not so suitable I think it would be an advantage because a single row can be shared by many tables Here is what I have in mind. I would like to have some feed backs AbstractComponent AbstractRow AbstractTable
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 ]
Hi, my understanding of the composite pattern is that it is useful when you have one type A that is a composite of another type B and you need to be able to treat the composite object same as type B. So, it is the behaviour of the objects that should have something in common to make use of the pattern. In your example I don't see a need for a table to have same behaviour as a single row so I would not recommend using it. A good example for the composite pattern is the Component - Container - relationship in java.awt: the container contains lots of components and is itself a component, so it can be used as one. Chris
Joined: Apr 20, 2001
It does make sense. Thank for your input.
I’ve looked at a lot of different solutions, and in my humble opinion Aspose is the way to go. Here’s the link: http://aspose.com