Any Ideas?
-
Architecture question. The application is a very dynamic with hundreds of panes the user can selectively choose. Each pane does something different. Each pane communicates through a modified observer pattern to all the other panes that are created. There could be 10 panes or 50 at any given time. The user can create or close panes at any time. There will be more panes added through time so recoding previous panes is a big no-no. I’m looking for ideas or pattern to manage the concept of when a pane changes the state of the application/data and another panes observe the change and *only certain* panes would act upon the change. Keep in mind there is an infinite set of possibilities. Maybe in a metaphorical sense I’m looking for a type of key and door logic and the key only opens certain doors. The doors would be defined on creation of a pane. The key would be defined upon the act of state change. I tried using a class with get/sets and reflecting the answers and if they match it was a good key but it seems hackish. Any ideas would be appreciated.
-
Architecture question. The application is a very dynamic with hundreds of panes the user can selectively choose. Each pane does something different. Each pane communicates through a modified observer pattern to all the other panes that are created. There could be 10 panes or 50 at any given time. The user can create or close panes at any time. There will be more panes added through time so recoding previous panes is a big no-no. I’m looking for ideas or pattern to manage the concept of when a pane changes the state of the application/data and another panes observe the change and *only certain* panes would act upon the change. Keep in mind there is an infinite set of possibilities. Maybe in a metaphorical sense I’m looking for a type of key and door logic and the key only opens certain doors. The doors would be defined on creation of a pane. The key would be defined upon the act of state change. I tried using a class with get/sets and reflecting the answers and if they match it was a good key but it seems hackish. Any ideas would be appreciated.
Willliam Doman wrote:
I’m looking for ideas or pattern to manage the concept of when a pane changes the state of the application/data and another panes observe the change and *only certain* panes would act upon the change. Keep in mind there is an infinite set of possibilities.
Without more details of the requirements... I'll give it a try: How about multiple 'channels' in your observer, each view could then subscribe only to the 'events' it is interested in. Let's say you have a status update in one component, only those views that are actually stated interest (because they have subscribed to it) will be notified. On the other side if you change a GUI setting you still have the possibility to notify all active views. Another solution could be adding a 'manager' class which takes care of filtering events BEFORE they are distributed to observer(s). Events would get only where they belongs (that means your views can be simple and react on everything they get). My personal feeling is to avoid (middle) manager classes, they make e.g. code maintenance harder and information flow tends to be less elegant. Hope this gives you some ideas, happy designing! /Moak
-
Willliam Doman wrote:
I’m looking for ideas or pattern to manage the concept of when a pane changes the state of the application/data and another panes observe the change and *only certain* panes would act upon the change. Keep in mind there is an infinite set of possibilities.
Without more details of the requirements... I'll give it a try: How about multiple 'channels' in your observer, each view could then subscribe only to the 'events' it is interested in. Let's say you have a status update in one component, only those views that are actually stated interest (because they have subscribed to it) will be notified. On the other side if you change a GUI setting you still have the possibility to notify all active views. Another solution could be adding a 'manager' class which takes care of filtering events BEFORE they are distributed to observer(s). Events would get only where they belongs (that means your views can be simple and react on everything they get). My personal feeling is to avoid (middle) manager classes, they make e.g. code maintenance harder and information flow tends to be less elegant. Hope this gives you some ideas, happy designing! /Moak
I actually went down both of these paths at first and both seemed to work well when there was a static 10 or 20 sets of possibilities. As developer teams started pumping out panes it became apparent that a VERY dynamic pattern would be needed to block or allow flow of logic. Whether this logic of opening a door was in a middle manager class or on each pane the concept still needs a very strong and dynamic solution/pattern. On some of the MSDN forums it was suggested to use a Model-View-Controller and Event-Broker pattern but that would require a very time intensive and costly rewrite of some core components. =( I should have added to the original post is that each time a pane is created it will have a different key and door. In a basic example think of a pane with a simple grid that displays apples. The user adds the pane again that displays oranges. The two panes are linked but only work having to do with apples would affect the pane that shows the apples. Unfortunately the application is a very data intensive scientific/mathematical program so the key and door can be very complicated.
-
I actually went down both of these paths at first and both seemed to work well when there was a static 10 or 20 sets of possibilities. As developer teams started pumping out panes it became apparent that a VERY dynamic pattern would be needed to block or allow flow of logic. Whether this logic of opening a door was in a middle manager class or on each pane the concept still needs a very strong and dynamic solution/pattern. On some of the MSDN forums it was suggested to use a Model-View-Controller and Event-Broker pattern but that would require a very time intensive and costly rewrite of some core components. =( I should have added to the original post is that each time a pane is created it will have a different key and door. In a basic example think of a pane with a simple grid that displays apples. The user adds the pane again that displays oranges. The two panes are linked but only work having to do with apples would affect the pane that shows the apples. Unfortunately the application is a very data intensive scientific/mathematical program so the key and door can be very complicated.
Willliam Doman wrote:
I actually went down both of these paths at first and both seemed to work well when there was a static 10 or 20 sets of possibilities.
Without knowing more about your scenario... maybe you need to rethink your data distribution and split up responsibilities even further (breaking up one big problem into many smaller individual problems could help). Sometimes it's easier to have a manageable level of complexity in individual parts, than trying to handle all at once.
-
Architecture question. The application is a very dynamic with hundreds of panes the user can selectively choose. Each pane does something different. Each pane communicates through a modified observer pattern to all the other panes that are created. There could be 10 panes or 50 at any given time. The user can create or close panes at any time. There will be more panes added through time so recoding previous panes is a big no-no. I’m looking for ideas or pattern to manage the concept of when a pane changes the state of the application/data and another panes observe the change and *only certain* panes would act upon the change. Keep in mind there is an infinite set of possibilities. Maybe in a metaphorical sense I’m looking for a type of key and door logic and the key only opens certain doors. The doors would be defined on creation of a pane. The key would be defined upon the act of state change. I tried using a class with get/sets and reflecting the answers and if they match it was a good key but it seems hackish. Any ideas would be appreciated.
-
Willliam Doman wrote:
I actually went down both of these paths at first and both seemed to work well when there was a static 10 or 20 sets of possibilities.
Without knowing more about your scenario... maybe you need to rethink your data distribution and split up responsibilities even further (breaking up one big problem into many smaller individual problems could help). Sometimes it's easier to have a manageable level of complexity in individual parts, than trying to handle all at once.
I totaly agree with the concept of breaking the problem into smaller pieces help solve complex problems. Its the essence of what we should do in every solution. =) The solution could be as simple as the guts in a method signature such as bool OpenMyDoor(key) {/*code*/} The question is geared more twords managing the creation of keys and doors so they fit together and can be tested dynamically. I'm sure at some point they will want one key to open several doors... The Brooker with Model-View pattern seem to the most popular suggestion on all the boards. Looks like it might be a long night. =|
-
Willliam Doman wrote:
Each pane communicates through a modified observer pattern to all the other panes that are created.
communicates what?
I guess I wasn’t clear enough and I applogize I should have read the guide twice. It would have made all the difference for you I'm sure. The answer is *Anything* =)
-
I guess I wasn’t clear enough and I applogize I should have read the guide twice. It would have made all the difference for you I'm sure. The answer is *Anything* =)
:laugh: Sorry, I had the "Read the Guide" link in my signature from another post. Forgot to take it out on yours. My bad.
Willliam Doman wrote:
The answer is *Anything*
So it's untyped then? If so you could build a reflection based mechanism that works from meta data to avoid hard coding everything.
led mike
-
I totaly agree with the concept of breaking the problem into smaller pieces help solve complex problems. Its the essence of what we should do in every solution. =) The solution could be as simple as the guts in a method signature such as bool OpenMyDoor(key) {/*code*/} The question is geared more twords managing the creation of keys and doors so they fit together and can be tested dynamically. I'm sure at some point they will want one key to open several doors... The Brooker with Model-View pattern seem to the most popular suggestion on all the boards. Looks like it might be a long night. =|
Willliam Doman wrote:
The question is geared more twords managing the creation of keys and doors so they fit together and can be tested dynamically. I'm sure at some point they will want one key to open several doors
Perhaps a kind of 'routing tables' concept would work. Basically the distribution of data is not decided by the type of data... but instead by a runtime configuration for destinations. An example: one destination could stand for a collection of views (multicast) while another just for one single view (unicast). This might offer a level of indirection with better control over data flow.