Modeling an Intersection class
Hi,
What is the best way to model an relationship between two classes in object model ?
Assume there are a couple of classes.named A and B.
Assume there is a many-many relationship named "relation" between A and B.
From A, we can traverse this relationship to get a list of Bs. From B, we can traverse this relationship to get a list of A's.
Should I model a separate class named "Relation" and have a public API named addRelation(Relation) in the class B[or class A]. In thisWhile populating the model, the client creates a new Relation Class and then calls the former API to store the relation in A or B.
Is there a better way around ?
At first it seems natural to let A objects know about what B objects they're related to, and the other way around. But maybe it's better to keep them ignorant about that and keep the relationships in a separate class ABRelation or so.
In this way you get kind of a Strategy pattern where an ABRelation object is supplied when the A-B relationship is important in some situation. Also in this way you can easily juggle many sets of A-B relationships at the same time.
> Hi,
> What is the best way to model an relationship between
> two classes in object model ?
> Assume there are a couple of classes.named A and B.
> Assume there is a many-many relationship named
> "relation" between A and B.
> From A, we can traverse this relationship to get a
> list of Bs. From B, we can traverse this relationship
> to get a list of A's.
Sounds like A would have a List of B child references and visa versa. That will do it.
> Should I model a separate class named "Relation" and
> have a public API named addRelation(Relation) in the
> class B[or class A]. In thisWhile populating the
> model, the client creates a new Relation Class and
> then calls the former API to store the relation in A
> or B.
I'd only have a separate class Relation if it had non-trivial behavior associated with it.
What you're proposing is necessary in relational database modeling, but objects can deal with it the way that I cited above. It's not necessary for objects.
%
To me, the OP seems to be actually talking about decoupling. However (and this is usually the case when I think about value objects, etc.) I do not understand how coupling would be decreased. Before you had A depending on B and vice versa. Now, you have A depending on Relation (and vice versa) and B depending on Relation (and vice versa). Coupling has increased! Now, if this was in a discussion of tiering, I could stomach it. But if not, then I agree with Duffy that the easiest way is to simply have the objects maintain references to each other. (Though be careful if you are ever going to to traverse the graph in memory recursively).
- Saish
It depends on the nature of A, B and relation. For example, if there are very many A and B and many of them equal, you can save much memory keeping less copies of A and B. In this case you don't want to ruin simularity of A and B objects by adding relation property. You should manage relation externally in this case, and providing relation adding through A and B calls would be misleading.
On the other side, it may be wrong to create relation ouside the related objects. Relation should exist only when it's registered for them. So, if changes in object may change relations, they should be able to access those relations, or changes of A and B themselves should be provided through relations.
Copies? Who'd be holding copies? They're just lists of references, not duplicates.%
> You should manage relation externally in
> this case,
I share your view that to hold the A-B relation separate from A and B may be beneficial but I wouldn't go as far as to say should.
Introducing another class may not decrease the complexity but it makes the coupling between the A and B classes looser.
.u..j
As, I said, "in this case". It's not much of an option, as if you don't have distinct instances of A and B for relations, you can't hold that relation there.
duffymo
I mean copies of value type, when for common values only single instance is hold (that is, "no copies").
> .u..j
> As, I said, "in this case". It's not much of an
> option, as if you don't have distinct instances of A
> and B for relations, you can't hold that relation
> there.
>
> duffymo
> I mean copies of value type, when for common values
> only single instance is hold (that is, "no copies").
Not following you here. You instantiate instances of A and B and assign them to references that point to them. If you want to add a B to the List maintained by A, you add the reference to the List. There's only one instance in memory, with two references pointing to it: the original reference to B and the one held by the child List in A.
The additional memory cost is the storage of the references in the List. That's what I'm thinking.
%
> As, I said, "in this case". It's not much of an
> option, as if you don't have distinct instances of A
> and B for relations, you can't hold that relation
> there.
I'm not sure I understand the point you're making. The A-B relationship must be modelled somehow. From a design perspecitive you have two main alternatives. Either you let the A and the B classes know about their relationships to B and A classes repspectively, or you take the A-B relationship out of A and B altogether and keep it in a separate class.
From an implementation perspective you can keep the actual implementation of the relationship local to the A and B classes (in the form of lists for example), or you can keep the relationship in some global data structure which the A and B classes utilize to fulfill their obligation to know about the relationship.
I've concentrated on the design perspective. At first it seems natural to let the A and B classes know about their relationship to B and A, but I think it may also be beneficial to remove knowledge of this relationship out of these classes altogether and keep in a separate class. This makes A and B classes more decoupled. The A-B relationship can be passed along where it's needed ala the Strategy pattern.
That's the point. One of previous comments was that if ralations are stored outside of A and B, it may be wrong to let A and B know about relations and introduce the interface hinting of storing those relations within A and B (like A.addRelationWith(B b) method). I know, interface and implementation are different things, but sometimes when interface is contrary to implementation, implementation may become very tricky and difficult to improve...
> That's the point. One of previous comments was that
> if ralations are stored outside of A and B, it may be
> wrong to let A and B know about relations
Wrong? Why? To keep them decoupled? If that's the goal, then you have to take those methods out of the A and B classes and put them in the Relation class. But that's just a design decision.
When things start feeling complicated and convoluted, perhaps it's a sign that you should rethink your design. Go back to your criteria and see what you need to do to satisfy them.
%
When it comes to the implementation of the A-B relationship I think it's better to keep it in a separate class regardless of whether the A and B classes know about their relationship with the B and A classes or not.
At first it seems natural that A and B should know about their respective relations but on second thoughts I think it is worth investigating what happens with the total design if they don't and the relationship instead is isolated to a separate class. To know you would need to know more. It depends on what operations on the A-B relationship are anticipated.
Like I said earlier, I see the need in relational modeling but not for objects. Nobody has given a compelling reason for separating the relationship into a separate class yet. I've heard of no rich behavior, just vague references to the benefits of decoupling. I'm not convinced.%
> Like I said earlier, I see the need in relational
> modeling but not for objects. Nobody has given a
> compelling reason for separating the relationship
> into a separate class yet. I've heard of no rich
> behavior, just vague references to the benefits of
> decoupling. I'm not convinced.
I feel there's too little information to continue but regarding the benefits of decoupling it's not just a vague reference. The introduction of a separate Relation class would definately reduce the coupling between A and B. Generally decoupled designs are a main objective in OO so this possibility shouldn't be discarded without an investigation.
Say A and B are Person and Club. One Person can be member of many Clubs and one Club can have many Person members.
A global Relation class would allow you to easily keep track of a changing relation. For example you could have a list of Relation objects describing the situation year for year over a 10 year period, one object for 1995, one for 1996 etcetera. In the decoupled situation this wouldn't effect the A and B objects at all. In the coupled situation you somehow would have to "reload" the A and B objects with the relationship for a specific year, or expand them to handle this "many of the same" situation.
Also say for example Person can participate not only in a relation with Club but also with Course. With a decoupled Relation class you could easily set up this new relationship without touching the Person class.
At some point you may want to define operations on whole Relation objects. Like you have the A-B and the B-C relation now please give me the A-C relation. This is definately easier to arrange with the relationships held in a separate class.
So, in my view, the more participating classes and the more the emphasis is on the relationships the more one benefits from the decoupled design. I see great benefits but it may not necessarily fit the OP's situation.
> I feel there's too little information to continue but
> regarding the benefits of decoupling it's not just a
> vague reference. The introduction of a separate
> Relation class would definately reduce the coupling
> between A and B.
Why is decoupling A and B a good idea? I know that loose coupling is an ideal to be sought for, but in the case where we KNOW that A and B are related, why is decoupling them beneficial? It's as if they're adopted children who have been prohibited from knowing that they're related. I don't see a compelling reason except the following orthodoxy:
> Generally decoupled designs are a
> main objective in OO so this possibility shouldn't be
> discarded without an investigation.
> Say A and B are Person and Club. One Person can be
> member of many Clubs and one Club can have many
> Person members.
So what's the benefit to a Club not knowing who its members are, or a Person not knowing which Clubs they belong to?
> A global Relation class would allow you to easily
> keep track of a changing relation.
So would have the 1:m relations built into both Person and Club.
> For example you
> could have a list of Relation objects describing the
> situation year for year over a 10 year period, one
> object for 1995, one for 1996 etcetera. In the
> decoupled situation this wouldn't effect the A and B
> objects at all.
The verb is "affect", for what it's worth.
> In the coupled situation you somehow
> would have to "reload" the A and B objects with the
> relationship for a specific year, or expand them to
> handle this "many of the same" situation.
I'll agree that membership history would mean changes - a Person would go from having a List of Clubs to a Map that would have start and end dates. I'll even agree that this might the specialized behavior that I was asking for at the beginning. Maintaining history is certainly richer behavior than just moving the m:n relationships out of the classes.
I hope you'll agree that this can still be managed inside the classes without the separate class to track it.
> Also say for example Person can participate not only
> in a relation with Club but also with Course. With a
> decoupled Relation class you could easily set up this
> new relationship without touching the Person class.
This could be a ternary relationship that is another problem.
> At some point you may want to define operations on
> whole Relation objects. Like you have the A-B and the
> B-C relation now please give me the A-C relation.
> This is definately easier to arrange with the
> relationships held in a separate class.
I think it's those operations that would determine whether or not I'd have a separate Relation class. Without them, I see no compelling reason to do this.
> So, in my view, the more participating classes and
> the more the emphasis is on the relationships the
> more one benefits from the decoupled design. I see
> great benefits but it may not necessarily fit the
> OP's situation.
I agree with this.
%
> So would have the 1:m relations built into both Person and Club.Should be "having", for what it's worth. 8)%
> > Like I said earlier, I see the need in relational
> > modeling but not for objects. Nobody has given a
> > compelling reason for separating the relationship
> > into a separate class yet. I've heard of no rich
> > behavior, just vague references to the benefits of
> > decoupling. I'm not convinced.
>
> I feel there's too little information to continue but
> regarding the benefits of decoupling it's not just a
> vague reference. The introduction of a separate
> Relation class would definately reduce the coupling
> between A and B. Generally decoupled designs are a
> main objective in OO so this possibility shouldn't be
> discarded without an investigation.
>
> Say A and B are Person and Club. One Person can be
> member of many Clubs and one Club can have many
> Person members.
>
> A global Relation class would allow you to easily
> keep track of a changing relation. For example you
> could have a list of Relation objects describing the
> situation year for year over a 10 year period, one
> object for 1995, one for 1996 etcetera. In the
> decoupled situation this wouldn't effect the A and B
> objects at all. In the coupled situation you somehow
> would have to "reload" the A and B objects with the
> relationship for a specific year, or expand them to
> handle this "many of the same" situation.
>
> Also say for example Person can participate not only
> in a relation with Club but also with Course. With a
> decoupled Relation class you could easily set up this
> new relationship without touching the Person class.
>
> At some point you may want to define operations on
> whole Relation objects. Like you have the A-B and the
> B-C relation now please give me the A-C relation.
> This is definately easier to arrange with the
> relationships held in a separate class.
>
> So, in my view, the more participating classes and
> the more the emphasis is on the relationships the
> more one benefits from the decoupled design. I see
> great benefits but it may not necessarily fit the
> OP's situation.
I will repeat: how does the above reduce coupling... over the entire system? You now have A coupled to Relation and B coupled to Relation. Formerly, only A and B were coupled.
- Saish
Saisha at 2007-7-20 11:40:04 >
Good point, Saish.
I'd also submit that if A and B were in the same package that it wouldn't matter much.
I think coupling between packages is far more important than within a package. It's that coupling that makes testing harder to do, because I have to drag more and more "stuff" in to make a JUnit test work.
If the classes within a package interact with each other it's no big deal. It might actually be a good measure of cohesion within the package.
%
> I will repeat: how does the above reduce coupling...
> over the entire system? You now have A coupled to
> Relation and B coupled to Relation. Formerly, only A
> and B were coupled.
It reduces the coupling between A and B and that's the point. It will also keep the coupling low if/when the number of participating classes grow.
Basically you have the Mediator pattern and it's maybe the most coupling reducing pattern there is. Instead of having A, B, and later maybe also C and D etcetera holding the relationships with each other themselves, their relationships are mediated by Relation. To add a new class E won't affect A, B, C and D at all (quite a soap opera now -:).
So if you want to prepare for the possibility that,
- the number of participating classes increase,
- the relationships change over time, and
- you want to perform operations on whole relations,
then the intruduction of a Relation class should be considered. And yes, it will keep down the coupling of the whole system down.
Anticipating and handling change is the main objective of OO so I really don't understand why you're so negative to considering the Mediator pattern in this case.
Simplest thing that can possibly work.
I'm not against Mediator or any other pattern out of the box, but I still haven't heard a really good reason for why it's necessary in the case of two classes with an m:n relationship. It's overcomplicating something that shouldn't be that hard, IMO.
You keep telling me that decoupling the classes is good, but you haven't begun to tell me why. "Because I said so" isn't a good design guideline.
Occam's Razor says putting those collections in the classes to start out is a fine approach. I'd only change if that approach started causing me problems down the road.
%
> And yes, it will keep down the coupling of the whole system down. How so? Asserting something is true is not the same as proving it, IMO. I'm not saying I know that I am right. I am just saying you have not proven to me that you are.- Saish
Saisha at 2007-7-20 11:40:04 >
> I'm not against Mediator or any other pattern out of
> the box, but I still haven't heard a really good
> reason for why it's necessary in the case of two
> classes with an m:n relationship. It's
> overcomplicating something that shouldn't be that
> hard, IMO.
Tell me what's so complicated?
> You keep telling me that decoupling the classes is
> good, but you haven't begun to tell me why. "Because
> I said so" isn't a good design guideline.
It prepares the design for future change. That's the ultimate design guideline of OO. I've provided three specific examples of that.
> Occam's Razor says
I prefer a saying ascribed to Einstein: "Make everything as simple as possible, but not simpler".
> putting those collections in the
> classes to start out is a fine approach. I'd only
> change if that approach started causing me problems
> down the road.
That's the common newbie mistake. Just pick the first design that comes to your mind and then trot along with fixes until the program is one total mess.
The only motivation from you so far as to why the "ad-hoc" design is so simple is that William of Occam probably would have thought so -:)
And again, what's so complicated with the "Mediator inspired" design? It just relieves the participating classes of any knowledge of their relationships. One small leap of imagination and the future of the design is secured. -:)
Well, I don't think we get any further unless the OP offers more information.
> How so? Asserting something is true is not the same
> as proving it, IMO. I'm not saying I know that I am
> right. I am just saying you have not proven to me
> that you are.
Are you familiar with the Mediator design pattern? It reduces the coupling among classes by introducing a common mediator class. With only two classes involved the effect is minimal but when the number of classes increases there's a big potential reduction of coupling. In a "Mediator inspired" design Relation plays the role of a mediator.
> > How so? Asserting something is true is not the
> same
> > as proving it, IMO. I'm not saying I know that I
> am
> > right. I am just saying you have not proven to me
> > that you are.
>
> Are you familiar with the Mediator design pattern? It
> reduces the coupling among classes by introducing a
> common mediator class. With only two classes involved
> the effect is minimal but when the number of classes
> increases there's a big potential reduction of
> coupling. In a "Mediator inspired" design Relation
> plays the role of a mediator.
I agree that as the number of interactions increases, the Mediator pattern will eventually reduce coupling, in the same way that centralizing state in a database versus clustering reduces network chatiness. It's a classic 'handshake problem'. Once n gets high enough, it pays to centralize the interactions.
I was simply pointing out that for simple interactions, the pattern will actually increase coupling.
- Saish
Saisha at 2007-7-20 11:40:04 >
> I agree that as the number of interactions increases,
> the Mediator pattern will eventually reduce coupling,
> in the same way that centralizing state in a database
> versus clustering reduces network chatiness. It's a
> classic 'handshake problem'. Once n gets high
> enough, it pays to centralize the interactions.
So know you've known all along. Good -:)
> I was simply pointing out that for simple
> interactions, the pattern will actually increase
> coupling.
It's often the case with design patterns that you have to invest upfront to get the benefits later.
My point is that the "Mediator inspired" design is more likely to hold upp under change than the "ad-hoc" design. I've shown three different kinds of possible changes and only one concerns the addition of more classes (that can participate in relations). So reduced coupling is just one of the advantages of the "Mediator inspired" design.
> > I agree that as the number of interactions
> increases,
> > the Mediator pattern will eventually reduce
> coupling,
> > in the same way that centralizing state in a
> database
> > versus clustering reduces network chatiness. It's
> a
> > classic 'handshake problem'. Once n gets high
> > enough, it pays to centralize the interactions.
>
> So know you've known all along. Good -:)
>
What was it Sartre said? "I don't know what I think until I say it." :^)
> > I was simply pointing out that for simple
> > interactions, the pattern will actually increase
> > coupling.
>
> It's often the case with design patterns that you
> have to invest upfront to get the benefits later.
>
> My point is that the "Mediator inspired" design is
> more likely to hold upp under change than the
> "ad-hoc" design. I've shown three different kinds of
> possible changes and only one concerns the addition
> of more classes (that can participate in relations).
> So reduced coupling is just one of the advantages of
> the "Mediator inspired" design.
Fair enough. I've enjoyed the discussion.
- Saish
Saisha at 2007-7-20 11:40:04 >
BTW, Duffy, you absolutely must get this: http://forum.java.sun.com/thread.jspa?threadID=656041Props to YoGee!- Saish
Saisha at 2007-7-20 11:40:04 >
> It's often the case with design patterns that you
> have to invest upfront to get the benefits later.
Since we've been talking about a bi-directional 1:m relationship between two classes, I still don't see how Mediator is going to help.
It's not being a noob to say that your model demands bi-directional 1:m relationship and get on with it.
I suppose that attributing that quote to Einstein confers more status?
> My point is that the "Mediator inspired" design is
> more likely to hold upp under change than the
> "ad-hoc" design.
I agree that designing for change can be a good thing, but is that relationship really that dynamic?
What you're describing is also known as "small boy/girl with a pattern" syndrom. That's when overzealous folks who have read through GoF run around injecting patterns everywhere, even if they're not needed, all in the name of appearing clever.
> I've shown three different kinds of
> possible changes and only one concerns the addition
> of more classes (that can participate in relations).
> So reduced coupling is just one of the advantages of
> the "Mediator inspired" design.
Still don't agree.
%
> Fair enough. I've enjoyed the discussion.So did I. I often take a position and defend it just to see what may come out. -:)
> I agree that designing for change can be a good
> thing, but is that relationship really that dynamic?
Neither I nor you know that. The OP has offered very little about the nature of the problem. We're discussing two main design choises, the "ad-hoc" and the "Mediator inspired". I has to be in principle.
> What you're describing is also known as "small
> boy/girl with a pattern" syndrom. That's when
> overzealous folks who have read through GoF run
> around injecting patterns everywhere, even if they're
> not needed, all in the name of appearing clever.
Breaking the relationships out of A and B seems to resemble the Mediator pattern. I recognized this and pointed it out. Is this an overzealos use of patterns? Isn't this in fact one of the benefits of patterns, to make it easier to discuss design choises?
> Still don't agree.
There are two main design alternatives; the "ad-hoc" and the "Mediator inspired". They're about equally simple but the latter better prepares for change. I've shown that in my argumentation. Now what is it you don't agree with?
The only argument I've seen from you is: The "ad-hoc" design was the first that came to my mind so I suggest the OP uses that. You've demanded hard evidence from me but only managed to produce a reference to Occams razor for your own view. Very weak indeed.
> > Still don't agree.
(final take -:)
That's not the problem. The problem is that you give bad advice.
Good OO design prepares a system for future change. All design principles aim at accomplishing that. Some advanced techniques (patterns) initially increases complexity but the idea is the you get a generous return on that investment later in the form of less complexity growth.
In this case there's no advanced pattern involved. (I've just mentioned Mediator to aid the discussion). What's at play here is the simple principle saying that you can make a design more flexible by decoupling classes using interfaces.
Decoupling classes using interfaces is the mother of good OO design. You shouldn't advice people against it in the name of appearant simplicity. Especially not when you don't know anything about the design situation. In that case the obvious general advice must be to introduce the interface.
Your advice represents exactly what should be avoided. Namely a tightly coupled monolithic system in the hope that nothing will ever change in the future.
> > I'm not against Mediator or any other pattern out
> of
> > the box, but I still haven't heard a really good
> > reason for why it's necessary in the case of two
> > classes with an m:n relationship. It's
> > overcomplicating something that shouldn't be that
> > hard, IMO.
>
> Tell me what's so complicated?
"So" complicated? Nothing.
But let's do talk about measures for this problem. If we agree that number of classes and coupled pairs are two appropriate measures, then doing it my way, where a bi-directional one-to-many relationship between A and B is modeled with child Lists, then I have two classes (A and B) and one pair of coupled classes (A and B).
Your way, which has A and B talking to a Mediator, has three classes (A, B, and Mediator) and two pairs of coupled classes (A and Mediator, B and Mediator). My solution is lower on both measures.
> It prepares the design for future change. That's the
> ultimate design guideline of OO. I've provided three
> specific examples of that.
Mediator is good for those situations where you have n classes that all have to talk to each other. If you try to model that problem with my solution, you'll land in hot water, because in that case you end up with O(n*n) relationships. Using Mediator is a good thing that gets better as n gets large, because now you only have n relationships between each class and Mediator. Every airline that uses a hub & spoke arrangement agrees with you.
I don't disagree with that reasoning, either. I'm simply saying that n=2 in this case. As the metrics above demonstrate, Mediator actually makes this situation worse.
> I prefer a saying ascribed to Einstein: "Make
> everything as simple as possible, but not simpler".
Right. Einstein is agreeing with Occam. The essence of his remark isn't so far off Occam's. So why are you opposing the will of these two bright people? 8)
> The only motivation from you so far as to why the
> "ad-hoc" design is so simple is that William of Occam
> probably would have thought so -:)
Actually, I'm motivated by my own thinking, and the metrics I posted above.
> And again, what's so complicated with the "Mediator
> inspired" design? It just relieves the participating
> classes of any knowledge of their relationships. One
> small leap of imagination and the future of the
> design is secured. -:)
I think our fundamental disagreement is this: How likely is the design to change? If a parent-child relationship is established at the beginning and always remains so, then my design is a better choice. If the number of classes that need to communicate with each other gets large, then your Mediator is the better choice.
Sometimes that relationship won't change. I cannot imagine an Order class without a child List of OrderLineItems. I also don't see a large number of children being added to that Order class. I see no value whatsoever in hiding that fact from the parent Order class. That's when I would use the "noob" design, and leave Mediator for another day.
What I dislike about your argument, even if you intend it in a jokey, jocular way, is the condescending tone and the implication that I don't have the wit to understand the subtlety of your proposal. I think this response demonstrates that I do. I don't think I've taken that tone with you, and I've shown in the past that I'm willing to take instruction from you. We've both posted here for a long time, and you know who I am (as much as this forum will allow). So why the edge? It doesn't become you.
%
> My solution is lower on both measures.
It's minimally lower if at all.
You start out with a tight coupling between A and B. Both knows about each other. Now you isolate a common part of A and B called M and break it out.
Both A and B becomes thinner when M leaves. The resulting coupling is that M knows about A and B. A and B knows neither about M or each other anymore.
The cost of the above operation is minimal. The benefit is that the design becomes prepared for future changes right from the start. Changes like,
- The number of participating classes increase.
- Relations change over time and that should be tracked.
- You want to perform operations on whole relations.
> I don't think I've taken that tone with you
You've commented on my english mistakes. It's a powerplay technique. Don't listen to her she can't even spell.
When I argue and believe I'm right I can get quite emotional and it shows, especially when the argumentation gets a little heated. I try to avoid it but it's also kind of fun to give the opposition a small "pinch" now and then so they don't fall asleep -:)
<..u..j.>
> > Like I said earlier, I see the need in relational
> > modeling but not for objects. Nobody has given a
> > compelling reason for separating the relationship
> > into a separate class yet. I've heard of no rich
> > behavior, just vague references to the benefits of
> > decoupling. I'm not convinced.
>
> I feel there's too little information to continue but
> regarding the benefits of decoupling it's not just a
> vague reference. The introduction of a separate
> Relation class would definately reduce the coupling
> between A and B. Generally decoupled designs are a
> main objective in OO so this possibility shouldn't be
> discarded without an investigation.
>
> Say A and B are Person and Club. One Person can be
> member of many Clubs and one Club can have many
> Person members.
>
> A global Relation class would allow you to easily
> keep track of a changing relation. For example you
> could have a list of Relation objects describing the
> situation year for year over a 10 year period, one
> object for 1995, one for 1996 etcetera. In the
> decoupled situation this wouldn't effect the A and B
> objects at all. In the coupled situation you somehow
> would have to "reload" the A and B objects with the
> relationship for a specific year, or expand them to
> handle this "many of the same" situation.
>
> Also say for example Person can participate not only
> in a relation with Club but also with Course. With a
> decoupled Relation class you could easily set up this
> new relationship without touching the Person class.
>
> At some point you may want to define operations on
> whole Relation objects. Like you have the A-B and the
> B-C relation now please give me the A-C relation.
> This is definately easier to arrange with the
> relationships held in a separate class.
>
> So, in my view, the more participating classes and
> the more the emphasis is on the relationships the
> more one benefits from the decoupled design. I see
> great benefits but it may not necessarily fit the
> OP's situation.
</..u..j.>
I agree with duffmo.
..u..j. I think your a DBM new to the OO world or a code monkey.
First, what you just said in your example using a Relation Class is a pretty bad design. You just said an example that applies directly to the Composite Pattern.
> I agree with duffmo.
> ..u..j. I think your a DBM new to the OO world or a
> code monkey.
How did you know? Was it that I tried to anticipate the effect of future changes on the design? Or was it that I pointed at interfaces as a tool for breaking up tightly coupled classes?
> First, what you just said in your example using a
> Relation Class is a pretty bad design. You just said
> an example that applies directly to the Composite
> Pattern.
I can't recall mentioning Composite. Or do you suggest that breaking out the relation somehow IS the Composite pattern. I don't think so but you seem to be an experienced guy so maybe you could explain.
> That's not the problem. The problem is that you give
> bad advice.
>
> Good OO design prepares a system for future change.
Good design prepares a system for future expected changes. Poor design prepares a system for unlimited future changes (because you can't possibly provide for all possible futures.)
> All design principles aim at accomplishing that. Some
> advanced techniques (patterns) initially increases
> complexity but the idea is the you get a generous
> return on that investment later in the form of less
> complexity growth.
And you base that conclusion on what?
Looking through the forewards in the GOF book I don't see that 'benefit' listed.
It does however specifically say
Put simply, design patterns help a designer get a design "right" faster.
>
> In this case there's no advanced pattern involved.
> (I've just mentioned Mediator to aid the discussion).
> What's at play here is the simple principle saying
> that you can make a design more flexible by
> decoupling classes using interfaces.
>
> Decoupling classes using interfaces is the mother of
> good OO design. You shouldn't advice people against
> it in the name of appearant simplicity.
Yes one should. There are reasons to decouple. But just because it is helpful in some situations doesn't mean that it should be applied to every possible situation. Unneeded complexity in the name of idealism hurts a system just as much as other poor design decisions do.
> > I don't think I've taken that tone with you
>
> You've commented on my english mistakes. It's a
> powerplay technique. Don't listen to her she can't
> even spell.
Where do you say I did that? Certainly not "noob". That was only to emphasize that you were suggesting that I was noob, not to say you couldn't spell it. (That's how I write it.)
I think the argument I made had nothing to do with powerplay, and you know that.
>
> When I argue and believe I'm right I can get quite
> emotional and it shows, especially when the
> argumentation gets a little heated. I try to avoid it
> but it's also kind of fun to give the opposition a
> small "pinch" now and then so they don't fall asleep
> -:)
Nobody's being heated but you.
You're hardly arguing. You are repeating the same thing over and over, hoping that if you say it enough that it'll change somebody's mind.
I agree that designing for change is a smart thing to do. That's what interfaces are all about. But I only take design for change so far.
Nobody's falling asleep.At least I put that bit of thought into metrics and stating the conditions under which I would concede your point. It's more than you did.
%
> > I don't think I've taken that tone with you
>
> You've commented on my english mistakes. It's a
> powerplay technique. Don't listen to her she can't
> even spell.
Althernatively it could be that he thought you might like to know the correct usage though.
If you are commenting on "effect" versus "affect" it is actually a rather common mistake among first language english speakers. And one that I know I made myself up until just a few years ago when I read something about it (and I usually have to consciously think about the correct usage now.)
> > My solution is lower on both measures.
>
> It's minimally lower if at all.
But it is lower, and the numerics demonstrate that.
>
> You start out with a tight coupling between A and B.
> Both knows about each other.
Right - that's the point. Can you please explain the circumstances under which an Order class would not want to know about its OrderLineItem children?
> Now you isolate a common part of A and B called M and break it out.
Why do I want to isolate it? Especially since we're only talking about two classes?
> Both A and B becomes thinner when M leaves.
Both have a reference to their M instead of a List of children. How are the classes thinner?
> The
> resulting coupling is that M knows about A and B. A
> and B knows neither about M or each other anymore.
Saying they're decoupled does tell me why neither A nor B want to know about each other.
> The cost of the above operation is minimal.
Perhaps so in terms of code. But we haven't quantified what the effect will be on understanding or maintenance.
> The
> benefit is that the design becomes prepared for
> future changes right from the start.
Which may never come.
> Changes like,
> - The number of participating classes increase.
> - Relations change over time and that should be tracked.
> - You want to perform operations on whole relations.
It's funny, because I just read some bits out of "Pro Spring" that made me think about this problem. The book said it was generally a mistake to have a domain object model mirror a relational schema too closely. The tell-tale sign that they cited was to call for a relational class in a many-to-many relationship between two classes.
%
"The verb is "affect", for what it's worth."
Ah, now I see.
Not a powerplay. At least that's not how I intended it. If you took it that way, I'll apologize sincerely.
I tend to point out when people use "it's" instead of the possessive "its" or "you're" when "your" is correct. I know that IM and short messages are coarsening what we consider correct writing, but I still think it reflects poorly on me when errors like these creep into my writing.I assume that most people feel as I do. I'd rather have it pointed out to me when I'm wrong.
From now on I'll refrain from correcting you. I'll leave other people to form whatever impression they wish.
%
>
> Your way, which has A and B talking to a Mediator,
> has three classes (A, B, and Mediator) and two pairs
> of coupled classes (A and Mediator, B and Mediator).
> My solution is lower on both measures.
>
Given a relationship between A and B with the following parameters.
1. Many to Many
2. Bi-directional
3. No parent.
Then I am going to pick the third class solution every time. Realistically if just 1 exists then I am probably going to pick it.
I am not going to try to justify it however. I doubt the choice, without additional defined functionality, is going to make a significant difference in an application. And probably not measurable either.
> >
> > You start out with a tight coupling between A and B.
> > Both knows about each other.
>
> Right - that's the point. Can you please explain the
> circumstances under which an Order class would not
> want to know about its OrderLineItem children?
>
Errr....when is that going to be a many to many relationship?
> > Now you isolate a common part of A and B called M
> and break it out.
>
> Why do I want to isolate it? Especially since we're
> only talking about two classes?
>
> > Both A and B becomes thinner when M leaves.
>
> Both have a reference to their M instead of a List of
> children. How are the classes thinner?
That isn't the way that I would implement it.
What functionality do you envision that would require that?
>
> > - The number of participating classes increase.
> > - Relations change over time and that should be tracked.
> > - You want to perform operations on whole relations.
>
> It's funny, because I just read some bits out of "Pro
> Spring" that made me think about this problem. The
> book said it was generally a mistake to have a domain
> object model mirror a relational schema too closely.
> The tell-tale sign that they cited was to call for a
> a relational class in a many-to-many relationship
> between two classes.
I understand the first point. But I don't understand how the second can be generalized to lead to a failure of the first. Hopefully there was more explanation than that.
> Errr....when is that going to be a many to many relationship?
Oops - bad example. Obviously 1:m. Why didn't I think of that?
> That isn't the way that I would implement it.
A with a List of B, and B with its List of A - if not this, how would you implement it?
> What functionality do you envision that would require that?
If A has to talk to its M, it has to get a reference to it from somewhere. How else will it manage it?
> I understand the first point. But I don't understand
> how the second can be generalized to lead to a
> failure of the first. Hopefully there was more
> explanation than that.
It's one example of what they considered telltale signs.
Not following you here. "the first point" is discouraging a 1:1 correspondence between domain object model and relational schema. Correct? What do you mean by "the second"? The many-to-many table being realized as an object?
%
> "The verb is "affect", for what it's worth."
>
> Ah, now I see.
>
> Not a powerplay. At least that's not how I intended
> it. If you took it that way, I'll apologize
> sincerely.
>
> I tend to point out when people use "it's" instead of
> the possessive "its" or "you're" when "your" is
> correct. I know that IM and short messages are
> coarsening what we consider correct writing, but I
> still think it reflects poorly on me when errors like
> these creep into my writing.I assume that most
> people feel as I do. I'd rather have it pointed out
> to me when I'm wrong.
>
Myself I don't consider that it reflects poorly on me. Nor do I think less of other people. Some people that post here can't phrase an english sentence much less get small variations correct. That has nothing to do with their intelligence but rather that it is obvious that their first language is not english.
But it doesn't particularily matter to me even if english is their first language as long as they can get the point across.
Of course I don't go to great lengths to use 'correct' english either. Too many years of having that forced down my throat along with a voracious appetite for reading material which made it apparent that popular writers (fiction and non-ficition) didn't use it and yet still managed to make the point, and that lead me to the conclusion that it just wasn't that important. [Oopsy - was that a run on? :)]
However even so I still perceived your point in the post as being one of providing correct usage rather than having any other intent.
> Myself I don't consider that it reflects poorly on me.
I do. It also reflects badly on me when I mistake a 1:m for an m:n relationship. 8) I'd prefer to avoid gaffes like those.
> Nor do I think less of other people. Some
> people that post here can't phrase an english
> sentence much less get small variations correct.
> That has nothing to do with their intelligence but
> t rather that it is obvious that their first language
> is not english.
I'll agree that it shouldn't be held against someone whose first language isn't English. I don't make that allowance for myself, since it's the only language I know.
It doesn't denote a lack of intelligence; rather, a lack of care.
>
> But it doesn't particularily matter to me even if
> english is their first language as long as they can
> get the point across.
>
> Of course I don't go to great lengths to use
> 'correct' english either. Too many years of having
> that forced down my throat along with a voracious
> appetite for reading material which made it apparent
> that popular writers (fiction and non-ficition)
> didn't use it and yet still managed to make the
> point, and that lead me to the conclusion that it
> just wasn't that important. [Oopsy - was that a run
> on? :)]
>
> However even so I still perceived your point in the
> post as being one of providing correct usage rather
> than having any other intent.
Thanks, I hoped that was obvious. Perhaps not.
%
>
> > That isn't the way that I would implement it.
>
> A with a List of B, and B with its List of A - if not
> this, how would you implement it?
>
> > What functionality do you envision that would
> require that?
>
> If A has to talk to its M, it has to get a reference
> to it from somewhere. How else will it manage it?
>
A and B are conceptual ideals.
The 'talk' from A to B is also a conceptual ideal.
How I implement both is an implementation.
For a many to many relationship I am probably going to implement at least one other class that provides the functionality between them.
> > I understand the first point. But I don't
> understand
> > how the second can be generalized to lead to a
> > failure of the first. Hopefully there was more
> > explanation than that.
>
> It's one example of what they considered telltale
> signs.
>
> Not following you here. "the first point" is
> discouraging a 1:1 correspondence between domain
> object model and relational schema. Correct?
That isn't how I would interpret it. What is says is that
- A one to one relationship is not required.
- A one to one relationship is not necessarily ideal.
The last point suggests that some relationships, and only some, should be modeled using some other strategy.
> What
> do you mean by "the second"? The many-to-many table
> being realized as an object?
The second is that a many to many relationship class suggests, by its existance, that the domain model is flawed because it models the data model rather than the domain model.
>
> I'll agree that it shouldn't be held against someone
> whose first language isn't English. I don't make
> that allowance for myself, since it's the only
> language I know.
>
> It doesn't denote a lack of intelligence; rather, a
> lack of care.
>
Yes, but we are here to discuss Java (and/or computers in general) not english. So, to my mind, that is where one must take care.
> >
> > However even so I still perceived your point in the
> > post as being one of providing correct usage rather
> > than having any other intent.
>
> Thanks, I hoped that was obvious. Perhaps not.
Unfortunately I might be biased in this particular case as I am particularily aware of that particular case (affect vs effect). So that could influence how I read it.
> > > Still don't agree.
>
> (final take -:)
>
> That's not the problem. The problem is that you give bad advice.
Sometimes I do.
> Good OO design prepares a system for future change.
Agreed, but it should not assume that everything will change.
> All design principles aim at accomplishing that.
Not all. "Do The Simplest Thing That Can Possibly Work" is a principle of design in XP. What does that have to do with change?
> Some
> advanced techniques (patterns) initially increases
> complexity but the idea is the you get a generous
> return on that investment later in the form of less
> complexity growth.
Sometimes, if it's done correctly.
> In this case there's no advanced pattern involved.
> (I've just mentioned Mediator to aid the discussion).
I know what Mediator is.
> What's at play here is the simple principle saying
> that you can make a design more flexible by
> decoupling classes using interfaces.
I'll concede this. I've stated the conditions under which I think it applies and when it doesn't. Since your entire argument is based on the assumption that the number of coupled classes will be large, I've already said that under those circumstances I'd agree.
I've also explained the circumstances under which I think it's a bad idea. So who's giving bad advice - the person who is acknowledging the rule and explaining the circumstances under which it's true and not, or the one who is saying that it applies in all cases?
> Decoupling classes using interfaces is the mother of good OO design.
I thought the four hallmarks of O-O were abstract data types, encapsulation, inheritance, and polymorphism. Loose coupling is certainly desirable, but at the end of the day that value cannot be reduced to zero for every class.
> You shouldn't advice people against it in the name of appearant simplicity.
I didn't advise anyone against it. I explained when it applied and when it didn't. I'll leave that to readers to decide which applies to them.
> Especially
> not when you don't know anything about the design
> situation.
No more or less than you.
> In that case the obvious general advice
> must be to introduce the interface.
I disagree. I think that presenting a choice is far better advice. Who's handing out bad advice here?
> Your advice represents exactly what should be
> avoided. Namely a tightly coupled monolithic system
> in the hope that nothing will ever change in the
> future.
I've also seen a system constructed by folks who are married to patterns. They've created an overly complex system consisting of thousands of classes, often injecting duplicate hierarchies in the name of isolating one class from another. It's late, over budget, impossible to test, unreliable, prone to deadlocks, brittle, and in desperate need of a re-write.
God save us from pattern zealots.
%
>
> Not all. "Do The Simplest Thing That Can Possibly
> Work" is a principle of design in XP. What does that
> have to do with change?
>
Is is simpler to throw a rope across a gorge and tightrope walk across it or to build a rope bridge?
For myself the second seems much easier and I don't even know how to do it. As for the first I understand the mechanics completely but it still is not going to be a choice that I would define as simple.
I suspect a great number of people would agree with me. I suspect that few would go with the first choice though.
I also suspect that most of the time that those that follow behind would prefer that I went with the second choice as well.
>
> I've also seen a system constructed by folks who are
> married to patterns. They've created an overly
> complex system consisting of thousands of classes,
> often injecting duplicate hierarchies in the name of
> isolating one class from another. It's late, over
> budget, impossible to test, unreliable, prone to
> deadlocks, brittle, and in desperate need of a
> re-write.
>
> God save us from pattern zealots.
That is just over-engineering. One can do that without using patterns as well (at least formally given that patterns are really just what people do anyways.)
> >
> > Not all. "Do The Simplest Thing That Can Possibly
> > Work" is a principle of design in XP. What does
> that
> > have to do with change?
> >
>
> Is is simpler to throw a rope across a gorge and
> tightrope walk across it or to build a rope bridge?
The design choice in this case is obvious - the second is what anyone who isn't a member of Cirque de Soleil would choose.
Of course this has nothing at all to do with s'ware implementation. The consequences of a wrong choice are so much greater for your gorge trip.
That maxim was cited from XP. It was never claimed to apply to all situations in life.
It might be simpler to get from point A to B by walking, but I still drove to work this morning.
%
Now I recall why I asked about Order and OrderLineItem. It's obvious that it's a unidirectional one-to-many relationship if it's modeled the way that I understand it.
My point in bringing it up was not out of confusion for an m:n relationship. It was more of rhetorical question: For this particular case, does it ever make sense to shield the Order from knowledge of its OrderLineItems? Would it ever be a wise design to inject a Mediator between the two, or is allowing Order a List of child OrderLineItems acceptable?
I believe the answer is "no", that it's perfectly acceptable to allow that close coupling between the two. An OrderLineItem doesn't make much sense in the wild without its parent Order. In the relational world I can picture a cascading delete - DELETE the ORDER and the ORDER_LINE_ITEM rows go with it. It's composition.
%
> Is is simpler to throw a rope across a gorge and
> tightrope walk across it or to build a rope bridge?
Every rope bridge starts with a rope thrown across a gorge.
I suspect a more apt comparison is: which is simpler, a rope bridge or a steel truss bridge. The rope bridge is certainly simpler, and as long as you stay within its weight limitations, sufficient to the task.
As for a M:M relationship between two classes, in my experience such relationships are usually traversed from one direction or the other, which suggests that the simple "list in each object" approach is sufficient.
And usually easily refactored should a relationship-centric approach become more desirable ... similar, I think, to the use of the original rope bridge to carry the lengths of steel needed to build a truss bridge.
> > >
> > > Not all. "Do The Simplest Thing That Can Possibly
> > > Work" is a principle of design in XP. What does that
> > > have to do with change?
> > >
> >
> > Is is simpler to throw a rope across a gorge and
> > tightrope walk across it or to build a rope
> bridge?
>
> The design choice in this case is obvious - the
> second is what anyone who isn't a member of Cirque de
> Soleil would choose.
>
But which is simpler? That is the axiom right?
> Of course this has nothing at all to do with s'ware
> implementation. The consequences of a wrong choice
> are so much greater for your gorge trip.
>
> That maxim was cited from XP. It was never claimed
> to apply to all situations in life.
>
> It might be simpler to get from point A to B by
> walking, but I still drove to work this morning.
Well I was just having bit of fun but.....
The consequences of the wrong choice in medical software are pretty apparent. So should one use XP when creating medical software?
> Now I recall why I asked about Order and
> OrderLineItem. It's obvious that it's a
> unidirectional one-to-many relationship if it's
> modeled the way that I understand it.
>
> My point in bringing it up was not out of confusion
> for an m:n relationship. It was more of rhetorical
> question: For this particular case, does it ever make
> sense to shield the Order from knowledge of its
> OrderLineItems? Would it ever be a wise design to
> inject a Mediator between the two, or is allowing
> Order a List of child OrderLineItems acceptable?
Ever? Not sure.
Often? Seriously doubt it.
I doubt that there would even be a significant minority of cases that would need it.
>
> I believe the answer is "no", that it's perfectly
> acceptable to allow that close coupling between the
> two. An OrderLineItem doesn't make much sense in the
> wild without its parent Order. In the relational
> world I can picture a cascading delete - DELETE the
> ORDER and the ORDER_LINE_ITEM rows go with it. It's
> composition.
I can't come up with any plausible scenarios where that wouldn't be the case.
> > Is is simpler to throw a rope across a gorge and
> > tightrope walk across it or to build a rope
> bridge?
>
> Every rope bridge starts with a rope thrown across a
> gorge.
Yes?
That doesn't seem to address which is simpler.
>
> I suspect a more apt comparison is: which is simpler,
> a rope bridge or a steel truss bridge. The rope
> bridge is certainly simpler, and as long as you stay
> within its weight limitations, sufficient to the
> task.
>
Apt?
One can use a helicopter as well. But those don't have anything to do with the comparison that I was making.
Or perhaps you are suggesting one can't cross a gorge via a tight rope?
> The consequences of the wrong choice in medical
> software are pretty apparent. So should one use XP
> when creating medical software?
I'm not aware that XP has been applied to medical s'ware or any realtime systems. It started with a Chrysler payroll system, where the consequences of error are a bit less catastrophic than having a pacemaker fail or a space shuttle crash.
%
> Ever? Not sure.
Me, neither.
> Often? Seriously doubt it.
I've never seen a case where it was. I've never seen an egg that fell to the floor spontaneously go back together, but physics would tell me that it's possible, even if the chances are vanishingly small.
> I doubt that there would even be a significant
> minority of cases that would need it.
> I can't come up with any plausible scenarios where that wouldn't be the case.
Neither can I.
So why would I inject Mediator as UJ suggests I should if I'm following good O-O design principles by preparing for the possibility of that vanishingly small chance?
I can't think of a good reason, either.
%
> From now on I'll refrain from correcting you.
You're wellcome to correct me but why not in the form of a P.S. after your actual argument?
> I'll
> leave other people to form whatever impression they
> wish.
I make lots of little errors. I use it's instead of its, use has instead of have, use chose instead of choose, use beeing instead of being and I occasionally mix up similar words. But this is carelessness and the fact that I'm slightly dyslexic. As soon as I've fired away a post I immediately see such mistakes clearly, and I could correct them if given the opportunity.
The problem is that a native english speaker still will recognize my writing as being produced by a fairly proficient non-native speaker. Most native speakers here for example couldn't even tell me what's wrong with what I've just written. It just doesn't sound "native" right, but what exactly is wrong with it in grammatical and semantic terms?
I would like to improve but to help me it wouldn't be enought to point out mistakes at the "typo" level. And this after all is a technical forum. Content must be considered more important than form.
> A with a List of B, and B with its List of A - if not
> this, how would you implement it?
A many-many relationship between A and B can also be implemented using a matrix (a two-dimensional array).
> If A has to talk to its M, it has to get a reference
> to it from somewhere. How else will it manage it?
In the design I suggested A and B doesn't manage their relationship at all. For example to add a B object to an A object you talk to M.
> > From now on I'll refrain from correcting you.
>
> You're wellcome to correct me but why not in the form
> of a P.S. after your actual argument?
OK, I'll take that under advisement.
> I make lots of little errors. I use it's instead of
> its, use has instead of have, use chose instead of
> choose, use beeing instead of being and I
> occasionally mix up similar words.
I do, too. I'm not saying I don't.
> But this is
> carelessness and the fact that I'm slightly dyslexic.
> As soon as I've fired away a post I immediately see
> such mistakes clearly, and I could correct them if
> given the opportunity.
As do I.
> The problem is that a native english speaker still
> will recognize my writing as being produced by a
> fairly proficient non-native speaker. Most native
> speakers here for example couldn't even tell me
> what's wrong with what I've just written. It just
> doesn't sound "native" right, but what exactly is
> wrong with it in grammatical and semantic terms?
I'm not saying that it's not productive.
I take the view that care in small things is a reflection on each of us. We know that better than anyone in our profession. "Oops, I had a typo in that <href>" - sure, it's an easy-to-make mistake, but it could mean an HTTP 404 error for your app.
Certainly this forum isn't formal, but those things matter in business writing. Personally, I try not to let looseness creep into my e-mail and other communications at work.
> I would like to improve but to help me it wouldn't be
> enought to point out mistakes at the "typo" level.
> And this after all is a technical forum. Content must
> be considered more important than form.
I'll take the PS under advisement. You know I'll remember - I haven't refered to Microsoft in any way other than their company name since you chided me for it.
I'll apologize again if you took it as a hurtful thing. I can assure you that it wasn't intended that way. Sincerely, %
I think I'll concede point. It's agreed that an m:n relationship can be modeled either by using class member Lists in each one to maintain the references, or by externalizing the relationship into a separate class. (This is the way that relational databases are forced to do it.)
I think we've spelled out the circumstances under which each one might apply. I'll leave it to others to decide the wisdom of each for their situation.
%
> I think we've spelled out the circumstances under> which each one might apply. I'll leave it to others> to decide the wisdom of each for their situation.Yes especially since the OP doesn't show any interest.
> > Ever? Not sure.
>
> Me, neither.
>
> > Often? Seriously doubt it.
>
> I've never seen a case where it was. I've never seen
> an egg that fell to the floor spontaneously go back
> together, but physics would tell me that it's
> possible, even if the chances are vanishingly small.
>
For what we are dicussing I suspect there is more chance than that.
> > I doubt that there would even be a significant
> > minority of cases that would need it.
>
> > I can't come up with any plausible scenarios where
> that wouldn't be the case.
>
> Neither can I.
>
> So why would I inject Mediator as UJ suggests I
> should if I'm following good O-O design principles by
> preparing for the possibility of that vanishingly
> small chance?
>
In the one to many case? I don't see a need. (Keep in mind of course that I strongly object to designs that make guesses about future needs as well.)
In the many to many case? I don't know that I would categorize the intermediate object(s) as a mediator. I know in the past at least some of the classes I used for this didn't do much. Others did. But I still did use another class.
> I think I'll concede point. It's agreed that an m:n
> relationship can be modeled either by using class
> member Lists in each one to maintain the references,
> or by externalizing the relationship into a separate
> class. (This is the way that relational databases
> are forced to do it.)
Well technically there isn't anything that keeps you from doing without it in a database. And for some databases you can even do it 'correctly' (Oracle has at least one field type that would allow this.)
Myself I would still prefer the third table approach.
I would also prefer the third class approach in java (or other languages as well.)
> > Yes especially since the OP doesn't show any interest.Which doesn't usually stop any discussions.
> > I doubt that there would even be a significant
> > minority of cases that would need it.
>
> > I can't come up with any plausible scenarios where
> > that wouldn't be the case.
>
> Neither can I.
>
> So why would I inject Mediator as UJ suggests I
> should if I'm following good O-O design principles by
> preparing for the possibility of that vanishingly
> small chance?
>
> I can't think of a good reason, either.
Firstly I've called this design Mediator inspired mainly to counter a suggestion that this design was incapable of reducing coupling.
Secondly I find it strange that you cannot think of plausible scenarions where the Mediator inspired design comes in handy. I've posted this list several times,
- the number of participating classes increase,
- specific relationships change over time and you want to keep track of that, and
- you want to perform operations on whole relations.
> > Yes especially since the OP doesn't show any interest.
>
> Which doesn't usually stop any discussions.
No it surely hasn't. I was just trying to provoke the OP to say something. -:)
Many have assumed there are just two classes A and B involved in this case. But more often than not when you have many-many relationships in an application there are more classes than just two involved. If the OP would come back I'm quite sure he would confirm that he has used A and B as generic class names. In reality there are many A's and B's.
It's just a guess in this case of course but generally in my experience many-many relationships don't come alone, they come in bunches. You can as well design for this up front and this suggest the Mediator inspired design. It also prepares the design for other changes I've mentioned, which in my view are very likely for many-many relationships.
> Firstly I've called this design Mediator
> inspired mainly to counter a suggestion that
> this design was incapable of reducing coupling.
Jeepers.
Nobody said it was incapable of reducing coupling. I think I posted a response earlier that described how Mediator can take n classes with O(n*n) coupling and reduce that to O(n). (It's a more rigorous explanation of how it's done than what you've offered.)
I'm saying that I don't see how it reduces coupling for the specifica case of n=2 that started this discussion.
See the difference?
> Secondly I find it strange that you cannot think of
> plausible scenarions where the Mediator inspired
> design comes in handy.
Again, not true. I can certainly see the difference for cases when the O(n*n) curve crosses over the O(n). I just do not see it for this particular case where n=2.
See the difference?
I'm writing it this way because in spite of my best efforts to make clear what I object to in your solution you insist on repeating it ad nauseum.
> I've posted this list several
> times,
>
> - the number of participating classes increase,
> - specific relationships change over time and you
> want to keep track of that, and
> - you want to perform operations on whole relations.
Terrific. You're brilliant. Happy?
%
> > > Yes especially since the OP doesn't show any
> interest.
> >
> > Which doesn't usually stop any discussions.
>
> No it surely hasn't. I was just trying to provoke the
> OP to say something. -:)
>
> Many have assumed there are just two classes A and B
> involved in this case.
One has assumed that she knows that the OP doesn't use just two classes. I think we've established that only the OP still knows the true answer.
> But more often than not when
> you have many-many relationships in an application
> there are more classes than just two involved.
No, not more often than not. When I a Bill of Material can have many Parts, and a Part can belong to many Bills of Material, that's the way I model it.
> If the
> OP would come back I'm quite sure he would confirm
> that he has used A and B as generic class names. In
> reality there are many A's and B's.
Speculation. You don't know any better than we do. You can't be more or less sure than anyone who is saying A and B.
> It's just a guess in this case of course but
> generally in my experience many-many relationships
> don't come alone, they come in bunches. You can as
> well design for this up front and this suggest the
> Mediator inspired design. It also prepares the design
> for other changes I've mentioned, which in my view
> are very likely for many-many relationships.
You can only design for what you know. No one knows what they don't know. Design as best you can based on what you know. You find out if you're a success if you can add new features without excessive pain.
%
> I'm saying that I don't see how it reduces coupling
> for the specific case of n=2 that started this
> discussion.
>
> See the difference?
If you have a look at posts #19 where I carefully explain when and why The Mediator inspired design is good. In your reply #20 you don't acknowledge what I say. You just keep pushing the "ad-hoc" design and introduce Occams razor as a motivation. Under such circumstances it's hard to know where our views differ. Still is.
I've said from the beginning that if you have and always will have two classes A and B then you can as well use the "ad-hoc" design. I've been talking about WHAT-IF there's a change. THEN the Mediator motivated design is motivated.
I've also explained why the introduction of M doesn't increase the coupling in the case of two classes. Before you have A->B and B->A. Afterwards you have M->A and M->B. Also afterwards the A and B types have shrunk with the M type, so the total complexity of the interfaces are the same as before. So nothing really has happend after M has been broken out regardless of the metrics you use.
> > I've posted this list several
> > times,
> >
> > - the number of participating classes increase,
> > - specific relationships change over time and you
> > want to keep track of that, and
> > - you want to perform operations on whole relations.
>
> Terrific. You're brilliant. Happy?
Didn't you just complain about the condescending tone in my posts? -:)
So you've been aware of these possible changes all the time. Then how come that you in post after post keep claiming that you for your life cannot think of any possible changes whatsoever? That's why I sometimes feel I have to repeat stuff.
> You can only design for what you know. No one knows> what they don't know. Design as best you can based> on what you know.I don't share this view. Instead of repeating myself I refer to #31.
> > But more often than not when
> > you have many-many relationships in an application
> > there are more classes than just two involved.
>
> No, not more often than not. When I a Bill of
> Material can have many Parts, and a Part can belong
> to many Bills of Material, that's the way I model
> it.
I'm saying that when there's one many-many relationship in an application, there's often many. In your application you had BillOfMaterial-Part. Didn't you have any other such many-many relationship at all? I'm almost certain you did because many-many relationships most often come in bunches.
> > Every rope bridge starts with a rope thrown across a gorge.
> Yes?
>
> That doesn't seem to address which is simpler.
Actually, it does. Let's go back to reply #50, in which you respond to duffymo:
> > Not all. "Do The Simplest Thing That Can Possibly
> > Work" is a principle of design in XP. What does that
> > have to do with change?
> >
>
> Is is simpler to throw a rope across a gorge and tightrope walk
> across it or to build a rope bridge?
>
> For myself the second seems much easier and I don't even know how
> to do it.
You're falling into the fallacy that "simple" is the important word. The actual principle, which duffymo quoted, is "do the simplest thing that could possibly work".
If you are a tightrope walker, then the single rope is sufficient and is the simplest thing that could possibly work. If you're not -- or someone that needs to go across the bridge is not, then you need to do something else, but keep it simple -- going back to my reply #54, the rope bridge is a simpler solution than a steel truss bridge.
The point about a rope bridge starting with a single rope also brings up the XP principle of emergent design. The user story is to cross the gorge. The developer discusses that story with the user, and comes away thinking that a single rope may be sufficient. S/he implements that solution, and shows it to the user, who shakes his/her head. However, the development effort isn't wasted, since that rope becomes the foundation for the bridge.
Remember, since we're talking XP, the developer has a full-time on-site customer. S/he doesn't just throw a rope across the gorge because it's a solution to the problem, s/he does so because the customer things it's a good solution.
> If you have a look at posts #19 where I carefully
> explain when and why The Mediator inspired design is
> good.
I went back and read #19. Yes, you explain when and why a Mediator is good, by bringing in speculative classes C, D, through Z. That's the crux of your entire argument: that there WILL be "bunches" of other classes participating in these relationships. There might indeed be other m:n relationships in a given problem, but they don't all tend to converge on one clustered relationship between all the classes in the problem.
The part that's prominent by its absence is any acknowledgement of when your Mediator pattern would not apply. That's one problem I have with your argument - you cling to your point without acknowledging where it might fall down or be less optimal.
> In your reply #20 you don't acknowledge what I say.
See above - what's good for this goose is good for you, gander.
> You just keep pushing the "ad-hoc" design and
> introduce Occams razor as a motivation. Under such
> circumstances it's hard to know where our views
> differ. Still is.
We differ in the fact that I'm discussing the pros and cons of both sides of this design issue, while you only espouse one side and twist every scenario so that it supports your view.
You accused me in an earlier post in this thread of presenting bad advice. I think the best thing we can give to a person reading these threads is not dogma, but alternatives and their justifications, guidance as to when one might apply and one does not. I think I've done a far better job of that in this thread than you have.
> I've said from the beginning that if you have and
> always will have two classes A and B then you can as
> well use the "ad-hoc" design.
My memory tells me that you always followed that up with the speculation that one always has more than two classes, and that aggregation of classes always comes in bunches. If you've been saying that your approach doesn't apply to two classes, it's barely been a whisper.
> I've been talking about
> WHAT-IF there's a change. THEN the Mediator motivated
> design is motivated.
And I've simply been pointing out that all design choices are not equally dynamic. Somes an Address, with street1, street2, city, province, postal is not going to change.
> I've also explained why the introduction of M doesn't
> increase the coupling in the case of two classes.
I've presented the numerical argument that A-B means one pair of classes, and A-M and M-B means two pairs of classes. All you've done is state that it doesn't increase coupling. You haven't presented anything to support that except an argument from authority and you haven't refuted these simple numbers.
> Before you have A->B and B->A. Afterwards you have
> M->A and M->B.
You conveniently leave out A->M and B->M. Don't the classes have to have knowledge of their mediator?Without that knowledge, how can the get their relationship with B? That would make the comparison 2 pairs versus 4, and your solution is still top-heavy. Two classes for me, three for you. Are there any other metrics we should bring in?
> Also afterwards the A and B types have
> shrunk with the M type, so the total complexity of
> the interfaces are the same as before. So nothing
> really has happend after M has been broken out
> regardless of the metrics you use.
Yes, it has. See above.
> Didn't you just complain about the condescending tone in my posts? -:)
Why yes, I did. 8) This isn't condescension; this is exasperation.
> So you've been aware of these possible changes all
> the time. Then how come that you in post after post
> keep claiming that you for your life cannot think of
> any possible changes whatsoever? That's why I
> sometimes feel I have to repeat stuff.
It'd be far better if you'd bring in better evidence rather than arguments from authority. It's computer science, not computer faith. 8)
%
> I'm saying that when there's one many-many
> relationship in an application, there's often many.
But that's what bothers me: I bring up specifics, and you keep throwing in general, unprovable statements.
> In your application you had BillOfMaterial-Part.
Yes.
> Didn't you have any other such many-many relationship
> at all?
I might have, but they didn't impact this particular relationship.
A Customer might order one or more Parts, and a Part will have a Bill of Material. But the Customer need not have a relationship with BoM. If a Customer needs the BoM details for a particular Part, it can ask the Part for them.
Is this an example of when you'd have the Mediator shield the Customer from both Part and BoM?
If that's so, I'd fear that as I kept adding relationships that the Mediator interface would keep growing in size. How do you plan to deal with that?
> I'm almost certain you did because many-many
> relationships most often come in bunches.
"most often come in bunches" - so do faith-based arguments.
%
"You conveniently leave out A->M and B->M. Don't the classes have to have knowledge of their mediator? Without that knowledge, how can the get their relationship with B? That would make the comparison 2 pairs versus 4, and your solution is still top-heavy. Two classes for me, three for you. Are there any other metrics we should bring in?"
I think the heart of the matter here is this: For what value of n do the class and coupling counts swing in favor of the Mediator solution? We know that the "ad hoc" solution with be O(n*n), and Mediator should be O(n). So there is some value of n for which the advantage swings to Mediator and never goes back to the ad hoc solution.
Let's do the numbers for the situation where we have A, B, and C.
n = 3
number of ad hoc classes = A, B, C = 3
number of ad hoc relationships: A<->B, B<->C, C<->A = 6
number of mediated classes = A, B, C, M = 4
number of mediated relationships = A<->M, B<->M, C<->M = 6
OK, still in ad hoc's favor for class count at n = 3, but equal for relationships. How 'bout n = 4?
n = 4
number of ad hoc classes = A, B, C D = 4
number of ad hoc relationships: A<->B, A<->C, A<->D, B<->C, B<->D, C<->D = 12
number of mediated classes = A, B, C, D, M = 5
number of mediated relationships = A<->M, B<->M, C<->M, D<->M = 8
Now we see two patterns:
(1) Class count will always be in ad hoc's favor, because adding M always increases mediator's count by 1.
(2) However, we see a rapid increase in the number of relationships for ad hoc. For n >= 4 it's always in mediator's favor, and the advantage widens quickly as n becomes large.
I think this is more helpful than simply repeating a position like a mantra.
%
> I'm almost certain you did because many-many
> relationships most often come in bunches.
One last thought.
There might be many of these kinds of relationships, but they don't all have to know about each other. If I implement the Party-Organization pattern, where an Organization can have many Parties and a Party can belong to many Organizations, but that doesn't need to know about the Part-BillOfMaterial relationship if this happens to be an online ordering system.
What we're talking about for Mediator is what I've seen in data modeling books as ternary relationships, where all three entities do need to know about each other.
An example given by Toby Teorey in his text would be a Department, Engineer, Notebook ternary relationship. An Engineer would have an assigned Notebook and belong to a given Organization. Each class in that case would maintain references to the other two.
I've never seen a 4th order or higher relationship in any book.Can you cite any in your experience, UJ? Something concrete please, not speculation or projection.
%
> >
> > I can't think of a good reason, either.
>
> Firstly I've called this design Mediator
> inspired mainly to counter a suggestion that
> this design was incapable of reducing coupling.
>
> Secondly I find it strange that you cannot think of
> plausible scenarions where the Mediator inspired
> design comes in handy. I've posted this list several
> times,
>
> - the number of participating classes increase,
> - specific relationships change over time and you
> want to keep track of that, and
> - you want to perform operations on whole relations.
Never seen any of those future conditions happen for an existing one to many owned relationship.
Certainly possible that it might occur now, rather than in the future though. Although I still can't recall any that have though.
> > > Yes especially since the OP doesn't show any
> interest.
> >
> > Which doesn't usually stop any discussions.
>
> No it surely hasn't. I was just trying to provoke the
> OP to say something. -:)
>
> Many have assumed there are just two classes A and B
> involved in this case. But more often than not when
> you have many-many relationships in an application
> there are more classes than just two involved. If the
> OP would come back I'm quite sure he would confirm
> that he has used A and B as generic class names. In
> reality there are many A's and B's.
>
> It's just a guess in this case of course but
> generally in my experience many-many relationships
> don't come alone, they come in bunches. You can as
> well design for this up front and this suggest the
> Mediator inspired design. It also prepares the design
> for other changes I've mentioned, which in my view
> are very likely for many-many relationships.
Bunches?
In my experience many to many relationships are rather rare. And even when there is more than one the actual relationship dynamics is unique to each, which of course means that a different solution is required for each.
> > > Every rope bridge starts with a rope thrown
> across a gorge.
>
> > Yes?
> >
> > That doesn't seem to address which is simpler.
>
> Actually, it does.
Err...no it doesn't.
>Let's go back to reply #50, in
> which you respond to duffymo:
>
> > > Not all. "Do The Simplest Thing That Can
> Possibly
> > > Work" is a principle of design in XP. What does that
> > > have to do with change?
> > >
> >
> > Is is simpler to throw a rope across a gorge and
> tightrope walk
> > across it or to build a rope bridge?
> >
> > For myself the second seems much easier and I don't
> even know how
> > to do it.
>
> You're falling into the fallacy that "simple" is the
> important word. The actual principle, which
> duffymo quoted, is "do the simplest thing
> that could possibly work".
There are only two parts to that statement based on your choice of emphasis: 'simple' and 'could possibly work'.
I don't know about you but I only build software that actually does work. The people I work with only build software that actually does work. The customers that I work with expect to have software delivered that actually does work.
I can't think of a single situation where it is reasonable that anyone would think that they would be building software that doesn't work.
Thus I took that statement to suggest that 'simple' is much more important than the part about working.
Are you suggesting that that is the most important part of that statement? Why? Do you work with a lot of people that create simple solutions that don't work? Or complex solutions that don't work?
>
> If you are a tightrope walker, then the single rope
> is sufficient and is the simplest thing that could
> possibly work. If you're not -- or someone that needs
> to go across the bridge is not, then you need to do
> something else, but keep it simple -- going back to
> my reply #54, the rope bridge is a simpler solution
> than a steel truss bridge.
>
But not the question.
Given that both do work, and presumably you are not claiming that the tight rope doesn't, then there is no other criteria for the decision.
Your scenario is providing a solution that is based on some other criteria besides 'simple' and 'it works'.
So what is that criteria?
> The point about a rope bridge starting with a single
> rope also brings up the XP principle of emergent
> design.
The point of that to me is to suggest that either I don't know how to build a real bridge or to obscure my example (that it is an actual solution.)
You can of course make your own point extending from my post, but that has nothing to do with what my original post pointed out.
> The user story is to cross the gorge. The
> developer discusses that story with the user, and
> comes away thinking that a single rope may be
> sufficient. S/he implements that so
