Christopher Bennage : Featured

Using Lambdas to get at properties

Christopher Bennage — Thu, 17 Jul 2008 00:36:00 GMT

This is a somewhat made-up scenario based on a recent project. My client has not given me permission to discuss the specifics of the application (yet), so I apologize for keeping it vague. I hope you don't give up before the payoff.

The Problem

Imagine an application, where a user can create "styles" and those styles can be applied to shapes. The application uses WPF to visualize the shapes with the styles applied. (Perhaps it's a design tool meant for Hanselman's BabySmash?) Let's say that there are three kinds of shapes: a line, a circle, and a bull's eye.

Each shape has specific attributes that can be styled, and the these attributes are unique to each shape. Here's a simple listing of possible attributes:

Line	Circle	Bull's Eye
Stroke	Fill	Outer Fill
Thickness	Stroke	Inner Fill

Now, we have three classes to represent the styles: LineStyle, CircleStyle, BullsEyeStyle. The Fill and Stroke attributes are all of type Brush. Furthermore, all three classes derive from ShapeStyle.

Now, imagine that we have to construct instances of these styles for some data that comes in the form of an API that we don't control. The constructor for LineStyle might look like this:

public class LineStyle : ShapeStyle
{
    public LineStyle(ForeignLineStyle style)
    {
        Thickness = style.StrokeThickness;
        Stroke = style.StrokeBrush;
    }

    public Brush Stroke { get; set; }
    public double Thickness { get; set; }
}

That's simple enough, but remember the properties are of type Brush, and we don't really want our instances of LineStyle to share the same Brush with instances of ForeignLineStyle. Luckily, Brush has a Clone method! Yeah! Only, what if the Brush is null? Okay, we'll change it to this:

public class LineStyle : ShapeStyle
{
    public LineStyle(ForeignLineStyle style)
    {
        Thickness = style.StrokeThickness;
        Stroke = (style.StrokeBrush != null)
                     ? style.StrokeBrush.Clone()
                     : null;
    }

    public Brush Stroke { get; set; }
    public double Thickness { get; set; }
}

Now, every time I have a property of type Brush on one of these style classes the pattern is the same. I start copying and pasting. (Do you smell something?) Hmm, what if I have lot of Brush properties? Many more than I initially listed in the table. I sure feel like I am repeating myself.

At this point, my instinct is to extract this pattern into a method. But how do I do this? The properties are unique to each class, and using reflection would be way overkill.

Lambda Magic

What I want is a method that takes the brush from ForeignLineStyle, and the setter for a property of type Brush. Using a lambda for the setter, I am able to create:

public static void SetBrush(Brush brush, Action<Brush> property)
{
    var value = (brush != null)
            ? brush.Clone()
            : null;

    property.Invoke(value);
}

For this to make sense, you need to recognize that a setter is a essentially a method with a signature like this:

delegate void PropertySetter<T>(T value);

That signature is the same as Action<T>.

Now, I can modify LineStyle to look like this:

public class LineStyle : ShapeStyle
{
    public LineStyle(ForeignLineStyle style)
    {
        Thickness = style.StrokeThickness;
        SetBrush(style.StrokeBrush, brush => Stroke = brush);
    }

    public Brush Stroke { get; set; }
    public double Thickness { get; set; }
}

Notice that the second parameter is :

brush => Stroke = brush

and not simply

()=> Stroke

The latter is for the getter and would match Func<T>.

After Thoughts

Arguably, this doesn't accomplish much. The repetitive code had a small footprint, and the SetBrush method is likely to throw off other developers.

It's up to you to decide it's applicability, but a least it's one more tool in the box.

(Thanks to Rob Eisenberg, who wrote some code that planted this ideas in my head.)

TemplateBinding: a bridge between styles and templates

Christopher Bennage — Fri, 04 Jul 2008 04:30:09 GMT

This is partially a follow-up to my last post contrasting control templates and styles. Like I mentioned before I've been working on an application that has required a custom theme. In addition to styling the standard controls like text boxes and expanders, we've had to create a number of custom controls as well. That has added up to a lot of control templates.

This recent work has emphasized the importance of the template binding. (Beatriz Costa first helped me get a handle on template binding here.) TemplateBinding is a special markup extension specifically designed for binding values in a template. (That's a bit of a circular definition, isn't it?) TemplateBinding is the mechanism that allows us to inject values into our templates, or to parameterize them.

An Example

First, imagine that we have a resource dictionary where we have defined a set of brushes that we'll use as the palette for our application. We might go about building a control template for the ToolTip control like this:

<ControlTemplate x:Key="ToolTipTemplate"
                 TargetType="ToolTip">
    <Grid>
        <Border x:Name="DropShadow"
                Focusable="False"
                CornerRadius="3"
                Background="Black"
                Opacity="0.4"
                Margin="3 3 0 0" />
        <Border Background="{DynamicResource NormalControlBackground}"
                BorderBrush="{DynamicResource NormalControlBorder}"
                BorderThickness="1"
                Margin="0 0 3 3"
                CornerRadius="3"
                Padding="6">
            <ContentPresenter TextBlock.Foreground="{DynamicResource NormalControlText}" />
        </Border>
    </Grid>
</ControlTemplate>

This control template is too rigid. What if another team member needs to create a special ToolTip in just one place with a background color other than NormalControlBackground? They would probably write some markup like this:

<Button Content="History Eraser Button">
    <Button.ToolTip>
        <ToolTip Background="Red" 
                 Foreground="White"
                 Content="Don't press it!" />
    </Button.ToolTip>
</Button>

Sadly, they would discover that it wouldn't work. The control template doesn't know anything about the properties we set on the ToolTip in the markup. Everything is defined in the control template and it's self contained. We really want the template to be able to use the properties that are set on the control. The template above can be rewritten to do that:

<ControlTemplate x:Key="ToolTipTemplate"
                 TargetType="ToolTip">
    <Grid>
        <Border x:Name="DropShadow"
                Focusable="False"
                CornerRadius="3"
                Background="Black"
                Opacity="0.4"
                Margin="3 3 0 0" />
        <Border Background="{TemplateBinding Background}"
                BorderBrush="{TemplateBinding BorderBrush}"
                BorderThickness="{TemplateBinding BorderThickness}"
                Margin="0 0 3 3"
                CornerRadius="3"
                Padding="{TemplateBinding Padding}">
            <ContentPresenter TextBlock.Foreground="{TemplateBinding Foreground}" />
        </Border>
    </Grid>
</ControlTemplate>

Using the template bindings allows the control template to pick up the values that are supplied directly on the element, or on the style applied to the element. That means that the Button markup above would work, or we could even create a style for the special case tool tip that looks like this:

<Style x:Key="WarningStyle" TargetType="ToolTip">
    <Setter Property="Background" Value="Red" />
    <Setter Property="Foreground" Value="White" />
</Style>

Handling the Default Values

If you use a control template with template binding, and don't provide any values on the control, what happens? The default values of the bound properties are used. There are many cases where this is not what you want though. If your intent was to have a global look for tool tips based on our first example, then you want the template to use some specific brushes as well a few other things.

In this case, you can use a style to set the desired defaults. To apply a style to a control for an entire application, set its TargetType and don't provide a key. The style will also need to be added to (or merged into) the resource dictionary of application. The style is also used to set the custom template for the control (otherwise you'd have to set the Template property on every instance of the control.)

Here's an example style to accompany our template:

<Style TargetType="ToolTip">
    <Setter Property="Background" Value="{DynamicResource NormalControlBackground}" />
    <Setter Property="BorderBrush" Value="{DynamicResource NormalControlBorder}" />
    <Setter Property="BorderThickness" Value="1" />
    <Setter Property="Foreground" Value="{DynamicResource NormalControlText}" />
    <Setter Property="Padding" Value="6" />
    <Setter Property="Template" Value="{DynamicResource ToolTipTemplate}" />
</Style>

I'm interested in feedback. If you find this useful, or too basic, or whatever, please let me know!

Thoughts on ALT.NET

Christopher Bennage — Sat, 15 Mar 2008 21:39:00 GMT

I just listened to Scott Hanselman interviewing Dave Laribee regarding ALT.NET. I really like what Dave had to say, and I encourage everyone to go and listen. I've been reticent about the ALT.NET movement (aside from my initial surge of enthusiasm.) I'm a bit shy when it comes to controversy, and even though I have strong evangelistic tendencies, I am also quick to shut up. ALT.NET has had its share of controversy.

I really like that Dave said it's not about the tools, it's about the principles. I am frequently asked about "good design" and "best practices". This is why I'm ALT.NET. (In fact, I have a series of posts on this topic that I intend to start after we're done with the book.)

There's an item in the interview that I'd like to comment on.

Scott asks (pardon my paraphrasing) why would the hypothetical Chief Architect of the Nebraska Department of Forestry have any interest in ALT.NET? The mythical Mort has pressing concerns, he just needs to get work done, why would he care about these conversations, discussions, and principles? Listen to the podcast for Dave's answer. However, my answer is this: he probably doesn't care and that's okay. I think that ALT.NET is about bringing good design and principle to the forefront. However, good ideas take a while to be adopted, to be democratized. Those who are hungry, we'll feed. Those who aren't, we'll wish them well. No hard feelings. Eventually, the good ideas will be institutionalized and they'll trickle down. (Have you noticed the "refactor" menu in Visual Studio?) I'm more concerned about convincing the institutions and the thought leaders. (Perhaps "convincing" is the wrong word, ALT.NET is more about "conversing" to me.) That's why it's good that ALT.NET is conversing with Microsoft, and that's also why I'm encouraged to see Microsoft paying attention to things like open source (though I know many people are angry about the kind of attention being paid).

Now go learn Ruby! :-)

TDD Example: Querying a Repository

Christopher Bennage — Mon, 27 Aug 2007 03:07:00 GMT

I'm always a little intimidated when I post code examples. There are a lot of smart (and opinionated) people out there reading blogs. Fear won't get us anywhere though. That said, I'm posting this example and asking for criticism.

Here's the story. A school of music needs to schedule auditions for incoming students. The faculty need to be able to view the schedule for the next two upcoming terms, and some of staff needs to be able to edit the audition schedule.

The "schedule" is really a set of rooms set aside on certain dates for certain types of students. For example, room 1874 will be used for violins on September 21. Thus, a ScheduledRoom is a certain on a certain date, with rules about who can audition there. Right now, we're just concerned with retrieving the list of rooms for a given Term, which is a unique combination of year and semester.

We have a repository for handling audition schedules, and a service that talks to the repository. The service is in turn accessed by a desktop client, and a web client. I'm going to focus on just the repository here.

namespace Specifications.Integrated.The_repository_for
{
    [TestFixture]
    public class the_audition_schedule
    {
        private AuditionScheduleRepository _repository;

        [SetUp]
        public void SetUp
        {
            _repository = new AuditionScheduleRepository();
        }

        [Test, RollBack]
        public void can_retrieve_the_list_of_scheduled_rooms_for_a_given_term()
        {
            //setup data for test
            Term fall2000 = a_term_for_Fall_2000();
            Term spring2001 = a_term_for_Spring_2001();

            schedule_a_room_for_(fall2000);
            schedule_a_room_for_(fall2000);
            schedule_a_room_for_(fall2000);
            schedule_a_room_for_(spring2001);

            //here's the actual code under test
            IList<ScheduledRoom> rooms = _repository.GetRooms(fall2000);

            //verify the results
            Assert.AreEqual(3, rooms.Count);
        }
    }
}

The methods a_term_for_Fall_2000(), a_term_for_Spring_2001(), and schedule_a_room_for_() are helper methods that do nothing more than persist some test data. In my [Setup], I create a new instance of _repository, so that it's fresh for every test.

What am I really testing here? An important question, Joey Beninghove has a good post on the topic here.

I want to ensure that GetRooms() behaves the way I expect. I expect it to return 3 out of the 4 terms I have persisted. The actual implementation for GetRooms() builds an NHibernate.ICriteria and call its List<>() method.

Thoughts? Comments? More examples to come...