Using the Observer Pattern in V10

Communication is a daily programming problem, either between technical teams or when notifying new changes to client.

The Design Pattern Observer is a solution to solve in V10 one of these problems - when one object property is changed, all concerning clients are informed and updated automatically.

Design Patterns

The Software Patterns, or Design Patterns, are an organized way of creating applications that are reusable for recurrent daily issues. In this respect, the software patterns are optimized and reusable solutions for the daily programming problems, making it easier to develop software with reusable solutions. 

Is it possible to develop a software without using software patterns? Yes! However, on one hand, the app answers the functional requirements to which it was designed that immediately please the Product Owner. But on the other hand, we are talking about an evolution to the solution that implies changes, time and costs, the Product Owner's opinion might be different.

In these scenarios, the evolution and maintenance of the solution may be assured by investing in a good pattern design and arquitecture, connecting in a starting phase, the software architects, the Technical Lead and, at the most, all developers.

Even though there is no set and finite number of software patterns, the truth is that there are hundreds of patterns and many more to be discovered. In the famous book Design Patterns 23 software patterns known in the area are presented, divided in several categories: creation, structural and behavioral patterns.

In this article, we will explore the pattern observer and instance its use in a practical case with version 10, allowing to solve a real integrator problem.

Observer 

This pattern, also known as Dependents, Publish-Subscribe, is applicable in situation where several customers need to be notifying of new system changes. In practice, when there is a change in an object property, all customers interested in being notified are informed and updated automatically.

The pattern observer presents several variations. However, there is a base design that describes the need for two objects: the subject and the observer.

The observer is the object responsible for showing the data, and the subject represents a business abstraction that is created based on the system requirement. Thus, when a change in object "A" occurs, the observer receives an automatic update.

The V10 Case - Example

When implementing, there is the need to change the value of a user field every time a specific client is identified. However, that field is available in the corresponding tab, but there is also a forma and context dashboard, and the change must be performed immediately.

Class responsible for changng the user field

public class UiEditorVendas : EditorVendas
{
	GestorCamposUtil getorCampos;

	public UiEditorVendas()
	{
		getorCampos = new GestorCamposUtil();

		Form1 f = new Form1(getorCampos);
		f.Show();
	}

	public override void ClienteIdentificado(string Cliente, ref bool Cancel, ExtensibilityEventArgs e)
	{
		var tab = CustomTabs.First(
			p => p is UserControl1 && 
				(p as UserControl1).Name == "UserControl1"
				) as UserControl1;

		tab.InicializaObserver(getorCampos);

		getorCampos.ValorCDUAlterado(13);
	}
}

Tab class for the user that will be notified by the state change

public partial class UserControl1 : CustomTab, IObserver
{
	private ISujeito gestorCamposUtil;

	public UserControl1()
	{
		InitializeComponent();
	}

	public void InicializaObserver(ISujeito Campos)
	{
		this.gestorCamposUtil = Campos;
		gestorCamposUtil.registrarObservador(this);
	}

	public void atualizar(double Campo)
	{
		textBox1.Text = Campo.ToString();
	}
}

Conclusion

Although software patterns exist to simplify the challenges posed to the developers, we don't always use them in daily solutions. The V10 case presented demonstrates that it can (and should) be the solution to solve real problems in a simple way and with code that is easy to maintain and develop.