Results 1 to 4 of 4
Thread: Is this a known design pattern?
Nov 3, 2009, 18:28 #1
Is this a known design pattern?
I've come across a problem which I suspect has been encountered before. I can't decide if it's a database design thing, or a software pattern thing, or what, so I'll explain.
My CakePHP app has widgets. Loads of them. It was necessary to record the fact that some widgets conflict with others. so I created a model called 'Conflicts', which looks something like this;
conflicts -------- id widget_id1 widget_id2
There is also some code to check, create or destroy conflicts between widgets. So far, so good.
My app also has doodles. I'm now finding that I need to record a link between doodles, e.g. doodle 35 is linked with doodle 36, etc. This doodles/links relationship works the same way as widgets/conflicts; they can be checked, created and destroyed. In understanding them, however, there is a difference between a conflict (things that can't go together) and a link (things that do go together).
Should I maintain two separate relationship models (conflicts and links), duplicating the functionality of the two? Or should I merge them together?
Is there a name for this kind of thing I could do some research on?
P.S. I'd like a better name than 'link', suggestions welcome.
Nov 3, 2009, 19:59 #2
- Join Date
- Sep 2009
- Melbourne, Australia
- 1 Post(s)
- 0 Thread(s)
You should try to avoid duplicating code: why not create a parent class ("relationship"?) with the basic check, create, destroy methods and inherit your conflict and link classes from it?
Nov 3, 2009, 21:43 #3
- Join Date
- May 2008
- 0 Post(s)
- 0 Thread(s)
Sounds like you are dealing with a conflict graph. If your problem maps nicely onto that idea, then you can model your code in various ways to represent the graph's structure, i.e. you could store your conflicts as an adjacency lists, you could store them in a way that you have a set of edges that point out to two conflicting things, etc. In general, I suggest creating or using pre-existing code to model graphs and then the operations that can be performed on them and then use a graph to model your conflicts.
Nov 6, 2009, 00:58 #4
Thanks Louis, I've actually implemented something like that now. There's a relationships model, which allows you to add/delete/check.
Other models can call it, e.g. Widgets can call addConflict, which in turn calls addRelationship, etc.
Peter, I looked into conflict graphs, but they're too much for my simple brain to comprehend!