Ayende @ Rahien

My name is Oren Eini
Founder of Hibernating Rhinos LTD and RavenDB.
You can reach me by phone or email:


+972 52-548-6969

, @ Q c

Posts: 6,026 | Comments: 44,842

filter by tags archive

Conditions and facts

time to read 2 min | 373 words

When working with UI, quite often some part of the UI is dependant on some condition. The problem is that this condition is often subject to change, and we need some way of dealing with those changes. That is why I created the following class:

public class Fact : INotifyPropertyChanged
	private readonly Func<bool> predicate;

	public Fact(INotifyPropertyChanged observable, Func<bool> predicate)
		this.predicate = predicate;
		observable.PropertyChanged += (sender, args) =>
		                              PropertyChanged(this, new PropertyChangedEventArgs("Value"));

	public bool Value
			return predicate();

	public event PropertyChangedEventHandler PropertyChanged = delegate { };

While it doesn’t looks like much, it does offer me a lot of value in terms of simplifying conditional logic. For example:

public Fact CanMovePrev
	get { return new Fact(CurrentPage, () => CurrentPage > 0); }

public void OnMovePrev()
	LoadPage(CurrentPage - 1);

Where CurrentPage is an Observable<T>, which I discussed previously.

My infrastructure knows about the naming convention and will automatically generate a Command and bind it to the MovePrev action, including both the action to execute upon commit and whatever or not we can execute this. For that matter, it will also gracefully handle can execute changes very easily. Here is the code to actually do that (I’ll spare you the convention based wiring code):

public class DelegatingCommand : ICommand
	private readonly Action action;
	private readonly Fact canExecute;

	public DelegatingCommand(Action action, Fact canExecute)
		this.action = action;
		this.canExecute = canExecute;
		var dispatcher = Dispatcher.CurrentDispatcher;
		if (canExecute != null)
			this.canExecute.PropertyChanged +=
				(sender, args) =>
					dispatcher.Invoke(CanExecuteChanged, this, EventArgs.Empty);

	public void Execute(object parameter)

	public bool CanExecute(object parameter)
		if (canExecute == null)
			return true;
		return canExecute.Value;

	public event EventHandler CanExecuteChanged = delegate { };

Tada! :-)



I like it, you basically encapsulate a condition and manage handling its invalidation. Although I'm not sure you need fact to be INotifyPropertyChanged, you could well just have a bog standard 'Changed' event.

Fact is nice and short as a class name but something niggles at me regarding a fact changing.. to me its more like an ObservableCondition, but obviously that doesnt sound as good ;).

Michael L Perry

What if the condition is based on more than one observable? Say for example, CurrentPage < TotalPages-1? How would you subscribe to both?

Ayende Rahien


Fact implementing INPC means that I can bind directly to it

Ayende Rahien


CompositeObservable to to rescue

Peter Morris

I used this:

public class ActionCommand : ICommand


    readonly Action

<object Action;

    public event EventHandler CanExecuteChanged;

    public ActionCommand(Action

<object action)


        Action = action;

        Enabled = true;


    bool enabled;

    public bool Enabled


        get { return enabled; }



            enabled = value;

            var canExecuteChanged = CanExecuteChanged;

            if (canExecuteChanged != null)

                canExecuteChanged(this, EventArgs.Empty);



    public bool CanExecute(object parameter)


        return Enabled;


    public void Execute(object parameter)


        if (Action != null)



Mike Minutillo

Could you possibly make the Command code even simpler if you used the Null Value Pattern to have your infrastructure insert a Fact that is always true instead of checking for null all over?

Ayende Rahien


I wouldn't call 2 if statements all over, but yes, I could have done that

Comment preview

Comments have been closed on this topic.


No future posts left, oh my!


  1. Technical observations from my wife (3):
    13 Nov 2015 - Production issues
  2. Production postmortem (13):
    13 Nov 2015 - The case of the “it is slow on that machine (only)”
  3. Speaking (5):
    09 Nov 2015 - Community talk in Kiev, Ukraine–What does it take to be a good developer
  4. Find the bug (5):
    11 Sep 2015 - The concurrent memory buster
  5. Buffer allocation strategies (3):
    09 Sep 2015 - Bad usage patterns
View all series


Main feed Feed Stats
Comments feed   Comments Feed Stats