Observer Pattern One of the overriding principles of object-oriented development is the proper assignment of responsibility in the given application. Each object in the system should focus on a discrete abstraction within the problem domain and nothing more. In short, an object should do one thing and do it well. This approach ensures that a crisp boundary exists between objects, enabling greater reuse and system maintainability. One area where the proper separation of responsibility is of special importance is the interaction between the user interface and the underlying business logic. During the development of an application, it is quite common for user interface requirements to change rapidly without an associated impact on the rest of the application. In addition, it is also likely that the business requirements will change without regard to the user interface. In many cases, both sets of requirements will change, as anyone with substantial development experience well knows. Without the benefit of separation between the UI and remainder of the application, modification of either portion may adversely impact the whole. The need to provide a distinct boundary between the user interface and business logic is a common problem that spans applications. As a result, a number of object-oriented frameworks developed since the inception of the GUI have supported the wholesale separation of the user interface from the remainder of the application. Not surprisingly (well maybe a little), most of these adopted a similar design pattern to provide this functionality. This pattern, commonly known as Observer, is advantageous in creating a clear distinction between various objects in the system. In addition, it is not uncommon to find this solution utilized within non-UI related segments of a framework or application as well. As with most other patterns, the usefulness of the Observer pattern extends far beyond its original intent.
Read On… http://msdn.microsoft.com/en-us/library/ms954621.aspx