views:

63

answers:

1

This is in relation to this question. The proposed answers involve adding a property to "Form1" that is of type "Form2" which answers the question asked. But what if we wanted a less coupled solution. What are your suggestions?

+1  A: 

The awnser you got was so coupled because you didn't provide allot of information on what your current design is and naming stuff form1 and form2.

To get a less coupled design you could do one of the following:

The easy solution Add a event to form2 that fires when X occurs (X being what determines that the notification icon needs to change). Then you could hook up a event handler at the place where you have a reference to the notificationicon and form2. This way form2 doesn't have to know about form1. This way the coupling is from form1 -> form2 (which it is anyways because form1 is instantiating form2) instead of form1 <---> form2

The advanced solution that covers much more then just this notification issue but the architecture of the whole app The other solution is to go with a clean UI design pattern like Model View Controller, Model View Present or Model View Viewmodel. Notification probally isn't a concern of the form itself but of some business entity. So that should probally expose it and not the forms themselve (which are only responsible for actually rendering something). If you abstracted the notion of notification out of the forms and into some sort of model you could even add more decoupling by using something like Inversion of Control (IoC) with a IoC container like structuremap or ninject and a INotificationManager interface for which a concrete type can be injected upon construction of the model class at runtime.

olle
Thanks for the reply. The original question wasn't mine, but it did get me to thinking.
Rob