Email Password Remember me?  Lost your password?

• Download example project - 30.3 Kb

Introduction

I searched for a long time to find an existing pattern/process/solution on the web to a long standing issue I have.

When writing a WinForms application (or VB6 or below, for that matter), the IDE encourages you to place a lot of code and logic in (or triggered from) control events. This is not (in my experience and opinion) a good solution, events can often be triggered for reasons the programmer didn't initially anticipate and lead to all sorts of problems. Also, it doesn't feel very object-oriented having lots of methods in forms that don't actually having anything to do with the form itself (being rather for controls on the form). Logic for the data relationships is often found in the control event or population code, when it is nearly always modeling an existing data relationship of some sort.

Let me explain further, with a trivial example application.

Imagine a simple little application designed to allow some very basic browsing of your top level hard disk directories. The main form for this application might look something like this.

The Drives list is initialized on startup, Top Level Folders populates when a Drive is selected, Files in Top Level Folder populates when a Top Level Folder is selected, and File Info is populated when a File is selected.

A set of common sense business rules for this screen might look like this:

Drive list:

• Filled at startup, nothing selected by default.
• When a Drive is selected, the Top Level Folders is changed to represent the folders on that Drive.
• No Top Level Folder will be selected by default, and the Files in Top Level Folder and File Info areas should be cleared.

Top Level Folder list

• Filled when the Drive list changes to contain the Top Level Folders on that Drive.
• No Top Level Folder will be selected by default, and the Files in Top Level Folder and File Info areas should be cleared.

Files in Top Level Folder list

• Filled when the Top Level Folder selection changes to contain the files in that selected folder.
• No file will be selected by default, and File Info should be cleared.

File Info

• Filled when the Files in Top Level Folder list changes to contain info on the selected file.

A traditional approach, in a WinForms type application, would probably look something like the code in Traditional.vb in the example project supplied, where code in the SelectedIndexChanged events of the three list boxes would be used to trigger the population code for the other lists.

Private Sub lstDrives_SelectedIndexChanged(ByVal sender As System.Object, _
        ByVal e As System.EventArgs) _
        Handles lstDrives.SelectedIndexChanged
    populateFolders()
End Sub

Private Sub populateFolders()
    Dim folders() As String
    Dim folder As String
    Dim drive As String

    If (lstDrives.SelectedIndex >= 0) Then
        drive = lstDrives.SelectedItem
        folders = Directory.GetDirectories(drive)
        ' Initalise the drives box only

        lstFolders.Items.Clear()
        For Each folder In folders
            lstFolders.Items.Add(folder)
        Next
    End If
    populateFiles()
End Sub

This approach doesn't scale very well as the form, controls, and the relationships become more numerous and complex. The main issues for me have always been:

• As it stands, the population code must sit in the form itself as it requires access to values in controls sitting on the form.
• The logic for the relationship between the Drives, Top Level Folders, and Files is found across different control events and population code. Whilst in this example, where the relationship basics and fundamentals (folders and file) are never likely to change, the events and population code are probably not the best place for the relationship rules to be enforced. This means that if any of the selected indexes are changed programmatically, without triggering the SelectedIndexChanged events (for example, when SuspendLayout() has been called), nothing will be updated, requiring more calls to the 'populate' methods from other places in the code, reproducing logic already found in other pieces of code.

A better approach perhaps, would be if each control knew what data it represented, and somehow received a notification of when that data changed. Furthermore, it would be useful if as part of that notification, the data that changed was also supplied. With this information, a control could typically repopulate itself. Additionally, if the control is populating itself, it can also decide whether something is selected by default or not, and if it does, that it should also be able to inform, any other control that uses this information, which item has been selected (or that no item has been selected, as the case maybe).

If all of that was true, then we would simply need to update the underlying data the controls watch, in anyway we want or need, and all the controls that use that data either directly or indirectly will be updated.

I effectively used those last two paragraphs as my specification for the "update" part of the GUI I've been working on, the GUIObserver is the result, and the example application supplied is the test bed for the ideas.

The example contains two projects: an Observer pattern library (CPObserver, written in C#), and the example project (written in VB.NET). I nearly always do my libraries in C# and my WinForms in VB.NET, just because I enjoy working in both languages and it keeps me fresh in both. I shall convert both examples, should demand require it.

Background

The article is based around the Observer pattern. To summarize this pattern:

A Subject (a piece of data/information) allows Observers (something that needs to know when a Subject changes) to attach themselves to it so it can notify them when it changes. A single Subject can have many Observers, and a single Observer may monitor many Subjects.

For more detailed information on the Observer pattern, try the following links:

• Observer Design Pattern in C# and VB.NET
• Implementing Observer in .NET
• Observer Pattern

The GUIObserver pattern was developed for an application I'm developing that contains many different related views of large amounts of related data, with several different types of visual relationships between the data, depending on how it's being viewed. The GUIObserver is meant to fulfill one distinct part of an application's architecture: updating control contents. The supplied example project was developed to prototype ideas before committing them to the main application (which has now been done with great success).

Observer Pattern

The classic Observer pattern doesn't quite support my requirements as it doesn't implement any method of passing information back with the notification of change. As I needed to send some data with the notification, I simply modified the Observer pattern to allow the Subject to send a single piece of data (as a System.Object) when it notifies Observers. Additionally, my concrete Observer (GUIObserver) uses a generalised GUIUpdate object that contains the code to physically update controls. The IGUIUpdate interface and its implementation will be discussed below.

Note: I did originally have the notifications sending instances of ISubject around, which seemed to make complete sense, but I've since changed it to System.Object for flexibility.

With our new Observer pattern implemented (see Observer.cs in the CPPatterns library example project), we can now create some simple Subjects that we can Observe. There is also the SubjectBase class that handles the storage of the actual subject content (as a System.Object) and some further derived classes to create basic data type subjects, i.e., StringSubject, LongSubject, BoolSubject etc.

We have three subjects that require watching, and they are all strings, so we set up three StringSubjects to represent the data we want to observe.

Private _selectedDrive As New StringSubject("")
Private _selectedFolder As New StringSubject("")
Private _selectedFile As New StringSubject("")

Now, we can modify the SelectedIndexChanged events in our ListBoxes to use our new Subjects instead of calling population methods. For the Top Level Folders list, the event code would now read:

Private Sub lstFolders_SelectedIndexChanged(ByVal sender As System.Object, _
        ByVal e As System.EventArgs) _
        Handles lstFolders.SelectedIndexChanged
    _selectedFolder.Subject = lstFolders.SelectedItem
End Sub

The same can be applied to other ListBoxes' events, and we have now successfully detached the user's interactions with the GUI from any direct logic other than storing the user's selection.

Using this pattern, we could now extend a control by having it implement the IObserver interface and fill the control on the Notify implementation, but we can generalize the case further to allow us to use the new Observer pattern on any control, group of controls, form, or any object.

We accomplish this by defining an interface that contains all the members required by a control to update itself. This interface could then be implemented on objects that a generic observer could use. The interface is called IGUIUpdate, and the generic observer is GUIObserver.

IGUIUpdate

IGUIUpdate defines the members needed for a control to update itself, these include:

• Init() which initializes the control as required (called only once).
• Reset() which resets the control back to its initialized state.
• Fill() which populates the control.
• ControlSubject, a property that may optionally contain a Subject instance that can be updated to reflect the selection of a control.
• NewData, a property that may optionally contain the new value of the Subject that caused the notification.

A Concrete/Base class, GUIUpdateBase, is available which offers basic implementation of the properties. Naturally, the methods are abstract as they are specific to the control being updated.

With this interface and base class defined, we can now develop a simple class to handle a specific control. The code shown is from the GUIObserver.vb form in the example project, and handles the Top Level Folder listbox in the example.

Private Class FoldersGUIUpdate
    Inherits GUIUpdateBase
    Private _list As ListBox
    Public Sub New(ByVal listBox As ListBox, _
                   ByVal controlSubject As SubjectBase)
        Me.ControlSubject = controlSubject
        _list = listBox
    End Sub
    Public Overrides Sub Fill()
        Dim folders() As String
        Dim folder As String
        Dim drive As String

        drive = Me.NewData
        If Not IsNothing(drive) And Directory.Exists(drive) Then
            folders = Directory.GetDirectories(drive)
            ' Initalise the drives box only

            _list.SuspendLayout()
            For Each folder In folders
                _list.Items.Add(folder)
            Next
            _list.ResumeLayout()
            ControlSubject.Subject = ""

        End If
    End Sub

    Public Overrides Sub Init()
        _list.BackColor = Color.Yellow
    End Sub

    Public Overrides Sub Reset()
        _list.Items.Clear()
    End Sub
End Class

As you can see, we inherit from the GUIUpdateBase and implement the three methods (Init, Reset, and Fill) required.

In our constructor, we store a pointer to the listbox we will update, and a pointer to a subject this listbox selection represents.

The Init() method is not that useful for ListBoxes, but I find it useful for more complex controls like grids and ListViews that may require some further runtime set-up (such as column/row headers etc.) before being populated.

The Reset() method simply returns the list to its initialized state.

The Fill() method is responsible for populating the control. In our example, the control needs a list of the folders at the root level of a specified drive. The specified drive is available in the Me.NewData reference because it's the SelectedDrive subject that this control is linked to. You can also see in the example that after repopulating the list, it uses the ControlSubject.Subject = "" line to ensure everything else knows that no folder is selected.

When the GUIObserver receives a notification, it first calls Init() if it hasn't already been called, followed by Reset(), and finally Fill().

GUIObserver

We now have the code to physically update the control in our GUIUpdate object, now we need to wrap it in an Observer so it can be called from a Subject.

The GUIObserver class implements our custom IObserver interface, and is initialized with an object that implements IGUIUpdate so that when Observer.Update is called, it can call the IGUIUpdate's Init(), Reset(), and Fill() methods as required. It can also set the NewData property to the value supplied in the notification so that IGUIUpdate methods can access the new value that caused them to be triggered.

Using the GUIObserver, we can now link our Subjects to the instances of generalized observers (GUIObserver) that contain their own references to objects that implement the IGUIUpdate. The code below comes from the GUIObserver.vb example, and shows the initialization of the GUIObserver and IGUIUpdate objects and their attachment to the subjects we created earlier.

Dim obDrive As GUIObserver = _
    New GUIObserver(New DrivesGUIUpdate(lstDrives, _selectedDrive))
Dim obFolder As GUIObserver = _
    New GUIObserver(New FoldersGUIUpdate(lstFolders, _selectedFolder))
Dim obFile As GUIObserver = _
    New GUIObserver(New FilesGUIUpdate(lstFiles, _selectedFile))
Dim obFileView As GUIObserver = _
    New GUIObserver(New FileInfoGUIUpdate(lstInfo))

_selectedDrive.Attach(obFolder)
_selectedFolder.Attach(obFile)
_selectedFile.Attach(obFileView)

Now that everything is in place, the runtime process flow (after initialization) is as follows:

• User selects a Drive from the list.
• The SelectedIndexChanged event fires and sets the _selectedDrive subject to the new value.
• The _selectedDrive subject notifies any Observers attached to it.
• The FoldersGUIUpdate instance created and attached to the Drive subject (_selectedDrive) is accessed and its methods called, it refreshes the folder list according to the Drive supplied in the notification via the NewData property.
• After refreshing the list, no items are selected, so it sets its ControlSubject (which is the _selectedFolder subject supplied at construction) to Nothing.
• The _selectedFolder notifies its observers (the FilesGUIUpdate class) and a similar process ensues.

Conclusions

Over the years, I have used several approaches to implement this part of an application's architecture, and my current one feels like the best :). Seriously though, I looked around for a pattern/process etc. to fulfill this particular niche, and (Model-View-Controller and Command patterns aside) was surprised I couldn't find anything (please point me in the direction of anything I've missed).

I have implemented this pattern in a much more substantial application with some quite complex visual relationships as well as used it for some simpler screens, and I have noticed the following positive things:

• My form code is much cleaner and easier to follow, mainly because it's not cluttered up with loads of code to populate controls on the form.
• Logic and code for populating individual controls is no longer sitting in a form itself, and can be placed in other classes/namespaces, allowing me to be much more flexible with my code organization.
• I can modify and switch whichver implementation I want to use for populating individual controls cleanly and easily, by implementing new GUIUpdate objects. I can also switch the implementations at run time by removing and attaching different GUIObserver instances that contain different IGUIupdate objects. This can allow controls (and screen space) to be reused with great ease.
• Logic for the visual relationships between data is mostly modeled in one area, the attachment of the Observers to Subjects.
• It can easily be extended to cater for very specific cases. For example, I have a GUIUpdate object that is registered with an observer that contains three private GUIUpdate objects of its own, for different types of output in a ListView. The main GUIUpdate object, when it receives a Notify, checks the data that was supplied, and based on this, it can identify which of the private GUIUpdate objects to use.
• GUIUpdate objects need not be responsible for just one control, it's completely up to the developer to define the constructor and contents of a GUIUpdate object. I have one that needs eight Labels, and out of pure laziness, I simply pass a pointer to the form in to get at them rather than the eight Labels individually.

Nothing is perfect though, and the following are still on my list to look in to:

• There is no inherent logic in the pattern to know whether an update is truly required (i.e., is the control actually visible), in my main app. Many of the controls are on tabs, and therefore, not always truly visible, but they are always updated. This can mean a slow update time when selecting certain (high level in my data relationships) items, as this triggers lots of child data control updates. The response time to show individual tabs is naturally quick but changing high level items can be slow. There is currently no inherent way in the design to offer a JIT mechanism for updates to offer quicker response times. Even if we do work out whether our specific control is actually visible, there is no way to delay the update call until it is visible. A possible solution (just thought of while writing this) is to simply have SelectedTab subjects that have to be set as an additional "key" before a control updates itself.
• The data relationships are not really "modeled", although the visual ones are, and centrally located more or less. I still feel there could be improvements to this part of the implementation. Ideas?
• I'm still not completely happy with the way external data is supplied to the GUIUpdate classes. Currently, it is supplied via the IGUIUpdate.NewData property which is set to the new value of the Subject that notifies the control. For simple data, this is fine, but when a control requires more than one piece of data (i.e., two database keys), then it must watch more than one Subject and cater for the fact that it might not have all pieces of data at once and therefore remember pieces that come in until it has a complete set. Without adding some form of call back request using delegates/events so that a GUIUpdate object can request data from its client (i.e., the form), which I don't want because events are optional, there is no enforcement of supply of data at compile time level. I couldn't think of another way to supply the objects with external data, ideas?

History

• v1.0 - 31/05/2006 - Submission to CodeProject.

You must Sign In to use this message board.

Per page 102550

FirstPrevNext

Mediator pattern popoh 3:04 7 Jun '06   Hi, I think that another pattern who helps the contruction of more reliable GUI is the mediator pattern. Another article who looks at this pattern is found in http://my.execpc.com/~gopalan/design/behavioral/mediator/mediator.html or in http://www.mindspring.com/~mgrand/pattern_synopses.htm#Mediator Thanks for attencion Mauricio Kiniz. Sign In·View Thread·PermaLink Some issues when GUI uses Observer pattern Jun Du 7:16 1 Jun '06   Chris, Thanks for the effort to put together this good article, which explains Observer pattern very well. Observer pattern probably is one the most often used design patterns originally recommended by the "Gang of Four". Another one I beleive is Singleton. The Observer model you discussed works on GUI in general, but it is less than ideal. Just like any other patterns, Observer has numerous limitations, particularly when it is used on GUI. You have listed some of them, but there are other important ones: 1) As with any interface-based design, your oberver model is an very intrusive and very public solution. Suppose you wanted to subscribe to many notifications, not one. This is typically what you do with GUI. A typical GUI generates a large number of events to which you might need to subscribe. 2) Another related problem is that use of an interface means that your Update() method must be public. Any code then can call it at any time. 3) That said, Observer has to be interface-based. Because if you don't use interface-based design, SubjectBase class would be tightly coupled to GUIObservser class. In other word, only GUIObserver instances can attach to a Subject. If some other class has a method that you want Notify() to call, you'll have to create a whole new SubjectBase-like class. So the problem is not in the interface; it is Observer model's limitation. 4) Observer model handles one-to-many subscription fairly well. By one-to-many, I mean that many observers subscribe to one subject. But when an event fires, the notifications to all the subscribed observers are linear, meaning that observers will get callback one by one following exactly the same order for every loop. There are variants that instead of direct callbacks, Subject puts a message on each observer's message queue. This way, they create a "random" notification mechanism. 5) Thread-safety issue. When the observer updates take longer than they are supposed to, the notification mechanism stops functioning. Thus, any piggy code in one update will affect the rest of GUI. To avoid this, Subject usually implements a multithreaded refresh mechanism. So now the thread-safety becomes an issue, as the observer's data has to be proteced while it's being updated. 6) .NET Delegate/Event model solves some of these problems and creates a safer, more robust, more encapsulated style of notification. Specifically, I think it solves the problems 1-3 cleanly. I'm not quite sure whether the event model is thread safe by itself, though. On Windows, I think the original messaging model and now the event model is an better option than primitive Observer model. I still use Observer patterns a lot, but not for replacing Windows messaging. On non-Windows platforms, I do see successful examples of using Observer pattern as a GUI notification mechanism (I guess, Unix/Linux doesn't have a messaging framework like Windows). I am pretty sure that many developers out there use Observer pattern on many other areas as well. Best, - It's easier to make than to correct a mistake. Sign In·View Thread·PermaLink Re: Some issues when GUI uses Observer pattern ChrisLee1 0:44 2 Jun '06   Thanks for you comments. I don't have much time left at the moment but I want to make a few comments. 1) Totally agree. Although this model is only really used for controls that display complex data, buttons, menu items etc. don't generally need it as they often have no visual updates after initialisation. So although the GUI generates a number of events not all of them ending in this mechanism. I do use it though to do things like update groups mutually exclusive menuitems though. 2,3) I agree and I think it's just one of those trade-off decisions you make at the time and probably is dependent on your personally coding style and tastes. 4) I have some objects that implement IGUIUpdate end up being called several times in sequence (because several different subjects are attached to the same Observer), collating the NewData values and only updating when they have a full "set", not a solution I'm currently happy with I admit. 5) Can you explain this more please. How do the notifications stop working (or do you mean there not arriving in a timely fashion?). 6) I don't know enough about thread safety, more reading for me. As a final comment, I don't think event/delegate model, replaces the Observer pattern but I agree it offers an alternative mechanism to accomplish the same thing, and I believe you could modify the Observer pattern to use Delegates instead of Interfaces. I also don't believe I've replaced windows messaging as such, we have always had delegates in the form of function pointers as callbacks, even VB6 (with some care) could handle this and 'C' etc use it extensively. Thinking all of this though I think I've come to the conclusion that in modern languages with extended features that some of the classic (and now quite old) patterns could updated to be made more efficient by using features in specific languages and I for one will certainly be bearing that in mind from now on when I look at patterns for use in my day to day work. Cheers Chris L. Sign In·View Thread·PermaLink Re: Some issues when GUI uses Observer pattern Jun Du 5:37 2 Jun '06   ChrisLee1 wrote: 5) Can you explain this more please. How do the notifications stop working (or do you mean there not arriving in a timely fashion?). Exactly, because it is very tight coupling. When notifying, Subject has to call into Observers' update() one by one. If one call has not returned promptly, or caught some exception, next call cannot be made. ... ... ... To keep it short, I don't see observer pattern is a better alternative to .NET event model for GUI. Rather, each has its own areas where it can be useful. - It's easier to make than to correct a mistake. Sign In·View Thread·PermaLink Re: Some issues when GUI uses Observer pattern ChrisLee1 23:28 4 Jun '06   I think I see what your saying now and agree, although couldn't they same issue occur (exceptions causing the next call NOT to be made), with .NET Events? Surely it would actually depend on how (whether?) you handle exceptions and is nothing to do with coupling? I still don't see it as using the Observer pattern as an alternative to the event model but as using the Observer pattern to apply some formal structure to an area of code in my (winforms at least) applications that previously didn't have (an OO based one for me at leat) one. In fact I believe we are actually really discussing implementation of the Observer pattern (using events or interfaces) as the underlying functionality of the pattern (having a "subject" notify things when it needs to) is the same regardless of events or interfaces and surely that the Observer pattern is actually about? Sign In·View Thread·PermaLink Re: Some issues when GUI uses Observer pattern ChrisLee1 0:20 5 Jun '06   I've just been working some examples through using the example app and would like to add another couple of comments. Because we can pass in the ControlSubject (which represents the Selected value in a control (i.e. the Selected Drive, Folder or File in my example app), if an exception occurs whilst trying to populate a control it can be caught and the ControlSubject value set to nothing (or actually "" in my example), setting this value will "notify" all the other controls that "observe" the ControlSubject to Update and because there data key (the empty ControlSubject) is not available their own internal logic will simple empty the control (Reset) and return. They may also empty their own ControlSubjects which would trickle the process through GUI heirarchy emptying all the controls as required. I also can't see why the length of an update should cause any problems. This is a "GUI" observer and as such most the notifications are at least started from a User Interaction (selecting an item in a list for example), so this are not async, background notifications to a queue or anything but almost physical notifications between the user and the underlying systems. As such any delays are (or should be at least) already visible to the user in the form of busy mouse pointers, disabled forms/controls etc. Obviously if something major goes wrong there things to deal with but thats the same in any synchronous process that doesn't inherently offer timeouts. Sign In·View Thread·PermaLink 5.00/5 Delegates and Events bwaide 21:55 31 May '06   Hi Chris, you've mentioned serveral articles for background information about the Observer pattern. I like to cite from on of them (Implementing Observer Patter in .Net[^]): "The built-in features of .NET help you to implement the Observer pattern with much less code. There is no need for the Subject, SubjectHelper, and Observer types because the common language runtime makes them obsolete. The introduction of delegates and events in .NET provides a means of implementing Observer without developing specific types." Would appreciate hints on why you think we should use your complicated handwritten solution instead of these build-in features of the .Net-plattform itself? I use them for several years now without any problems. Regards, Björn Sign In·View Thread·PermaLink 5.00/5 Re: Delegates and Events ChrisLee1 2:31 1 Jun '06   Hi Björn, thanks for you comments. The quote you mention is from part of the article which is about removing the dependency on the Observer interfaces from the Observer pattern which is easily accomplished in .Net with events and delegates, it still uses the Observer pattern throughout though, and the Observer pattern is what my article is primarily about. I only actually implement one small Concrete Observer (GUIObserver) that is a generalised observer that does indeed implement a slightly modified IObserver interface and this could easily be changed to use events and delegates instead. In fact with this design, the GUIObserver concrete observer implementation is the only observer you need for all you GUI updates, you don't need to code ANY Observer classes as I have already created the simple one you need. All you need to do is create the IGUIUpdate objects it uses. The built-in features you mention (events and delegates) would make up a very small and insignificant part of this design (namely replacing the Interfaces with delegates/events) which is at the designs lowest level of implementation, where as the article is really about making life easier higher up the chain. It would be very easy to modify the underlying code to use events & delegates instead of the interfaces but personally I think that would actually make it more complicated and harder to read. For these reasons I don't believe there would be any gain in modifying the underlying Observer implementation to use the techniques described in the article quoted. Can you please explain which part you found complicated so I might add more detail? One final thing I just thought of, events and delegates are optional, in that there is no built-in enforcement at compile-time that an event has been hooked up, therefore code may often work with no actual run-time errors but events are not called because of the if(OnEvent != null) OnEvent(...); calls that inevitably exist. I just think that for this kind of thing interface pointers are better because we (as developers) know and expect to have them instantiated before passing/using them, where as with events we fire them and forget largely, not caring whether they were actually called or not. All in all this leads to easier to read code. Sign In·View Thread·PermaLink Re: Delegates and Events bwaide 4:56 1 Jun '06   Hi Chris, thank you for your quick response. I guess it's all about my bad english that you have misunderstood my intention. I haven't digged into your code in depth, but I'm pretty sure that you can avoid using it by replacing it with delegates and events, because this concept is nothing more than a "short-cut" implementation of the observer pattern itself. You have specified "Attach" and "Detach" methods that corresponds directly to the "+=" and "-=" syntax of events. I agree with you that sometimes it's confusing when using this technique and you forget about attaching or detaching events, but I think that's what you have to pay if your goal is a well decoupled system. Furthermore this concept is used all over in the .Net Framework itself, especially in the Winforms namespace. So developers should be familiar with it. So unlike you I think it leads to easier code if you avoid introducing new techiques where already solutions exists. Nevertheless the observer pattern is a very important one and it's always good to know what's going on behind the scene, so one might take your article as an explanation of the pattern but not as a template using it in your own GUI code. Regards, Björn Sign In·View Thread·PermaLink Re: Delegates and Events ChrisLee1 0:00 2 Jun '06   Thats fair comment I think Björn. I agree that the underlying implementation could easily be changed to remove the dependency on the interfaces. In fact how did any of us do this sort of inter-object communication before we had formally named patterns? Usually with some form of call-back, which was usually a pointer to a function which is effectively the same as an Interface with a single method on it, which is effectively the same as Delegate. Sure you can avoid using the interface but I would still say that in this case, where the Observer implementation is hidden and the developer doesn't have to implement other observers, Just Subjects and GUIUpdates that there is no need and that the article is about using an Observer pattern, so it makes more sense to keep it (certainly for the purposes of discussion) in the classic format. Cheers Chris L. Sign In·View Thread·PermaLink 5.00/5 some questions Clark Li 21:54 31 May '06   Nice article Christ. I like how you can apply a design pattern into a real problem. I also thought about the problem of reducing duplicate UI logics. I don't mean to pick on you. Just have a few comments. 1. Why are you hard coding GUIUpdate class to take in just one subject as its parameter? Are you intentionally pairing a specific GUIUpdate class with a specific Subject class? 2. I thought it is strange to have the property Subject within the Subject class. To match its description, it should be named either state or value. 3. When you have complex UI relationships, you may run into recursive calls between two or more GUIUpdate classes. For example, let’s assume control 1 and control 2 are updates each other depending on selected values. An update to control 1 will result in update to control 2, which will result in update back to control 1, and so on. What’s your approach to this problem? Sign In·View Thread·PermaLink Re: some questions ChrisLee1 1:26 1 Jun '06   Thanks for you comments, feel free to pick away thats the point of putting the code up here. 1. I haven't coded GUIUpdate to take just one subject as it's parameter. Classes derived from GUIUpdateBase or inheriting IGUIUpdate are created by the you. You can pass as many subjects as you want in. My base implementation only supports the one ControlSubject property as convience and my examples only need a single ControlSubject per control. There is nothing to stop you adding additional properties or passing in anything your Fill() process needs in the constructor of your GUIUpdate objects. 2. I wasn't happy with the property name "Subject" either but I wasn't keen on the other names either, I considered the word "Content" to imply the "Contents of a subject", I suppose State matches the Observer pattern better but that word implies something else other than the actual contents of a control to me (I.e. is it enabled, visible or something). Strangley I don't remember considering "Value" at all, which is by far the most obvious candidate and makes the most sense, I've added changing the Subject property name to "Value" to my TODO list. 3. I can see what you mean but I can't think of an example to explain with. To stop your example recursing between to updates forever there must be a set of conditions/rules where Control 1 doesn't update Control 2 or vice versa (an invalid selection of some sort perhaps), these conditions would have to be implemented in the relevant Fill() events and would ensure that under the relevant conditions the ControlSubject for Control1 in part would be cleared and the this would make the Fill() in Control2 not populate and therefore not set a value that triggers changes in Control1 again. I think of ControlSubject's mainly as Primary Keys to my data, therefore once one becomes invalid all controls that depend on it, simply Reset() and the Fill() does nothing and they empty their ControlSubjects which in turns triggers the other controls to do the same. Does that make sense? I can see what you mean with number 3 but I can't think of a sensible example to discuss it with! Do you have one? Sign In·View Thread·PermaLink Re: some questions tkrafael_net 5:41 1 Jun '06   I think that we are confusing the Observer pattern with mvc pattern. Model View Controller (mvc) allow multiple views to share the same data and the update of interface is not mandatory, the controller sends the ui update automatically. The observer pattern is just like events and Delegates. The differences i think, is that using observer pattern allow a more accurate way to use and a more "object oriented" way, because the subject may be overriden and so on. Im sorry my poor english, im awful with this language Sign In·View Thread·PermaLink Re: some questions ChrisLee1 0:01 2 Jun '06   My (limited admittedly) experience with MVC led me to believe that it was an over engineered solution for my needs. I also looked at Commands/Command Management but that seems to more about keeping track of commands executed (for Undo/Redo) and the actual state (visible/enabled) of controls. I'm not sure because of my lack of experience with MVC but could the GUIObserver pattern not fit as part of it (View/Controller perhaps)?. I agree the Observer pattern is just like events and delegates, in fact as I've said in another post a Interface with a single method on is effectively the same as a Delegate anyway. Thanks for you comments, and you english is fine, almost certainly better than any of my "second" languages. Cheers Chris L. Sign In·View Thread·PermaLink Re: some questions tkrafael_net 10:45 2 Jun '06   OK, thanks. The mvc pattern, i think, uses the observer pattern to achieve the pattern objective: Create a way to display same data with different format, and when data change the views changes too. My experience with mvc is very basic, ive seen only one example in a brazilian book about design patterns. For Command management, youre right. I think that transactions in databases uses a similar command pattern. In this pattern i think we dont use for store actual state. Unless you need store a history for those controls. IMO, the best pattern and the more dificult to manage is the State pattern. I used only once in a project (a state connection, uses Listen, Accepted, TransferData, Error), but this pattern is very very flexible Sign In·View Thread·PermaLink

Last Visit: 13:25 23 Nov '09     Last Update: 13:25 23 Nov '09 1