Z pewnością sporo osób zetknęło się z wzorcem MVVM (Mode View ViewModel), należącym do wzorców prezentacji (takich jak MVC lub MVP – z którego nota bene się on wywodzi), albo o nim słyszało. Wykorzystuje się go w oprogramowaniu wykorzystującym Windows Presentation Fundation (WPF). Nie zamierzam się tutaj wgłębiać w meandry tego wzorca. Chciałem się tylko odnieść do pewnej jego (nomen omen) właściwości, dotyczącej sposobu powiadamiania widoku, że właściwość modelu uległa zmianie. Dokonuje się tego za pomocą interfejsu NotifyPropertyChanged w następujący sposób:

public class Person
{
	public string FirstName { get; set; }
	public string LastName { get; set; }
}

public class PersonViewModel : System.ComponentModel.INotifyPropertyChanged
{
	public PersonViewModel()
	{
		var person = new Person
		{
			FirstName = "Jan",
			LastName = "Nowak",
		};
		//Powiązanie Modelu z ModelemWidoku
		this.FirstName = person.FirstName;
		this.LastName = person.LastName;
	}

	public string FirstName
	{
		get
		{
			return firstName;
		}
		set
		{
			if (firstName != value)
			{
				firstName = value;
				OnPropertyChanged("FirstName");
			}
		}
	}

	public string LastName
	{
		get
		{
			return lastName;
		}
		set
		{
			if (lastName != value)
			{
				lastName = value;
				OnPropertyChanged("LastName");
			}
		}
	}

	#region INotifyPropertyChanged
	/// <summary> 
	/// występuje, gdy zmieniono wartość właściwości
	/// </summary> 
	public event System.ComponentModel.PropertyChangedEventHandler PropertyChanged;
	/// <summary> 
	/// na potrzeby informowania o zmianie wartości właściwości
	/// </summary> 
	/// <param name="propertyName">nazwa właściwości</param> 
	public void OnPropertyChanged(string propertyName)
	{
		var handler = PropertyChanged;
		if (handler != null)
		{
			PropertyChanged(this, new System.ComponentModel.PropertyChangedEventArgs(propertyName));
		}
	}
	#endregion

	private string firstName;
	private string lastName;
}

Jak widać nazwę właściwości (patrz wywołania OnPropertyChanged) podaje się w postaci łańcucha znakowego. Wyklucza to kontrolę tej nazwy z procesu kompilacji oraz czyni niewidzialną dla mechanizmów refaktoryzacji. Jeśli bowiem chciałbym zmienić nazwę jednej (lub obydwu) właściwości modelu widoku (PersonViewModel) za pomocą mechanizmów refaktoryzacji, to zmianie nie ulegną łańcuchy określające tę nazwę (lub nazwy). To niedopatrzenie mechanizmu refaktoryzacji nie zostanie następnie dostrzeżone na etapie kompilacji, a dopiero w momencie uruchomienia oprogramowania, kiedy spowoduje malowniczy błąd. I będzie to błąd tak pospolity, że aż wstyd bierze. To samo zresztą będzie miało miejsce, jeżeli wprowadzę jakąś literówkę w nazwie właściwości.

Podejrzewam, że zapewne istnieją dodatki do Visual Studio (coś mi się wydaje, że potrafi to Resharper), które wspomogą mnie w takiej sytuacji. Nie mogę jednak zapewnić, że każdy programista będzie dysponował Resharperem (np. podwykonawca, który zmodyfikuje kod) lub że kod nie zostanie zmieniony w inny sposób (na szybko w Notatniku i skompilowany z linii poleceń). Poza tym, co to za wzorzec, który wymaga ode mnie stosowania specjalizowanych narzędzi, zamiast standardowych mechanizmów środowiska. Co tu dużo mówić, to naturalne, że chciałbym mieć możliwość pełnej kontroli nad kodem, a ten wzorzec permanentnie mi to uniemożliwia – wręcz strzelam sobie w stopę. Osobiście widziałbym w wywołaniu System.ComponentModel.PropertyChangedEventArgs argument, który byłby symboliczną nazwą właściwości, a nie jej tekstowym odpowiednikiem.