This time my talk will be in Norwegian.

My talk – Javazone 2010 – Agenda

I recently ran into an example in Glue where I refactored towards LOD. I will share my thoughts on that here.

The problem

I am working on a new feature in Glue. In order to make room for that feature, I had to do some refactoring, to make it smoother to add that feature. What I found during the refactoring was this line (in the Mapper-class):

1

mapping.Relations.GetRelationsTowardsRight()

I found it because I already had some trouble with the Mapper class’ dependency on the Mapping class. I realized that I was exposing a lot of information, Mapper shouldn’t know about Mapping. This dependency made my refactoring job bigger. I strongly believe that objects should know as little as possible.

This is a good example of breaking LOD. I think breaking LOD isn’t always a big offense (Martin Fowler suggests we rename it “Suggestion of Demeter”), and I don’t think doing it here is my largest mistake. But now a new feature had brought the need for some refactoring, and at this point applying LOD seemed like a good idea. So it’s not only a question of where to apply a pattern, but also when.

The solution

The Mapping class is a kind of facade to the rest of the system. It is an attempt to make the API as simple as possible. That means it handles the creation of some objects. In our case this is how Mapping creates Mapper objects:

1

var mapper = new Mapper<LeftType, RightType>(this);

(Notice how Mapping passes itself in to Mapper). Mapper gets what it needs by calling:

1

mapping.Relations.GetRelationsTowardsRight()

Mapper gets a RelationContainer (the Relations property) from Mapping.

This breaks LOD. There is a simple fix in this case. The code passes a Mapping object, while what the Mapper wants is a RelationContainer. We should only pass the object it needs (in the Mapping class):

1

var mapper = new Mapper<LeftType, RightType>(Relations);

The Mapper now gets what it needs by calling:

1

relations.GetRelationsTowardsRight()

It’s fixed!

This way we have lowered the coupling, making Mapper unaware of Mapping, meaning that now it can access only what it needs, not a whole lot more. For me it is important that objects know as little as possible, and now it knows a whole lot less. It doesn’t care (or know) where the RelationContainer comes from. That isn’t its concern, and shouldn’t be either.

(The Law of Demeter is a rather academic specification of who is allowed to call who, specified here. Basically what it boils down to is that you shouldn’t ask for other objects from an object, and do an action on that. Or in other words, you should just use one dot per line.)

Not the “standard” solution

This solution is not how one normally is advised to resolve the breaking of LOD. Normally you’re supposed to hide the inner object. In this case it would mean that Mapper should be unaware of the fact that Mapping contains a RelationContainer, it should just ask Mapping to get the relations (a concept called encapsulation, it’s pretty standard object oriented thinking). Like this:

1

mapping.GetRelationsTowardsRight()

That’s a smart solution, if you’ve got the right problem. That solution enables Mapper to only know about Mapping, and none of its collaborators (hiding the RelationContainer in this example).

But the problem we have here is slightly different. What I found here was that Mapper should not know about Mapping at all. Mapper should only concern itself with the relations, and in this case Mapper should only receive the RelationContainer to work with. So the problem was that we depended on the wrong object altogether, not that we had the right object, and had to know about its collaborator. A subtle, but important difference. It’s important to be aware of what your problem is in order to find the right solution. It’s not always as easy as choosing the “standard” solution.

Reflections on Law of Demeter

LOD is just a concrete set of rules that aims to help writing less coupled code. You can do this without even knowing about LOD. In our case, focusing on separation of concerns can yield the same effects. As can sound object oriented thinking, like hiding as much as possible (not exposing things through properties or getters), focusing on knowing as little as possible, applying “Tell, don’t ask”, and so on.

The problem with concrete rules like LOD is that it works great if you understand the intention, but if you do not, you’re probably going to apply it wrong. And if you understand the intention, often you can get the effects without even thinking about LOD.

For me, I like the intention of LOD , but I do not think about it that often, as I use other guidelines to help me yield the same result. On the other hand, knowing the LOD principle have helped me on several occasions, as in this example, to see clearly what is going on.

Also, if you need to justify a style of programming that is heavy on mocking, LOD is an often used argument.

This refactoring is checked in as changeset 52023 in Glue. Compare that and the previous changeset to see what was done.

- Tore Vestues

Also no doubt, we have not had such excellent package management system in the .Net-sphere. So why not just make RubyGems work for .Net as well? That’s exactly what Dru Sellers have done with Nu.

This is a great idea, so I decided right away to make a Gem out of Glue.

To use it, start your favorite windows shell and type:

gem install gluemapping

Then go to your project directory (if you’re not already there) and type

nu install gluemapping

That’s it! The newest Glue-assemblies will be put in the lib-folder in your project directory.

Requirements:

1. You will need to install ruby. Download the latest rubyinstaller, and install it.
2. Install Nu:

gem update --system
gem install nu


You can find more information on Nu here.

The Gem is hosted at RubyGems, you can find information about it here.

- Tore Vestues

That means I am a C# MVP, and I am very proud of it!

I feel it is important for me to contribute to, and learn from, the technical communities around the world, and therefore I’m honored by receiving this award for my contributions. I will do my best to continue to contribute to the communities in the time to come, and I know I will learn a lot from them.

- Tore Vestues

There are many ways to use reflection, and the performance on them vary a lot. What we did was to try out every method and timing them to measure performance. These are the methods we tested: Normal property access, normal reflection, compiling and invoking a compiled expression, using Emit to create, compile and run the statement.

Normal property access

To compare the other methods, we measured the performance on accessing a property the normal way:

1

Run("Normal property access", () => { var city = address.City; });

It was no surprise that this was the fastest method.

Normal reflection (250 times slower than normal property access)

1
2

var cityPropertyInfo = typeof (Address).GetProperty("City");
Run("With reflection", () => cityPropertyInfo.GetValue(address, new object[0]));

This is what most of us think about when talking about reflection. This is also the by far most common method of reflection used in Glue. Although about 250 times slower than normal property access, this method has very strong sides compared to the other methods.

Invoking compiled expressions (twice as slow as normal property access)

1
2
3

Expression<Func<Address, string>> expression = x => x.City;
var func = expression.Compile();
Run("Invoke compiled expression", () => func.Invoke(address));

Using compiled expressions is another way of dynamically invoking members on objects. Due to the syntax exposed in the api in Glue, most mapping specifications enter Glue as (uncompiled) expressions. The fact that it is only about twice as slow than normal property access, is very promising. But there is a catch, a big one. In order to invoke this way, the expression must be compiled. It is not compiled when it enters Glue, so we have to include the time it takes to compile the expression as well.

Compile Expression and invoke it (51700 times slower than normal property access)

1
2
3
4
5

RunLong("Compile Expression and invoke", () =>
             {
                 var compiledFunction = expression.Compile();
                 compiledFunction.Invoke(address);
             });

Yes, if you have to compile an expression before invoking it, it takes about 200 times longer to do the operation than with normal reflection. Leaving this a unattractive method to use with Glue.

Using Emit, invoking a compiled expression (4 times slower than normal property access)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

private Func<Address, string> GetEmitDelegate()
{
    var dm = new DynamicMethod("TestMethod", typeof(String), new [] {typeof(Address) }, typeof(Address).Module);
 
    MethodInfo getCity = typeof(Address).GetProperty("City").GetGetMethod();
 
    ILGenerator il = dm.GetILGenerator();
    il.Emit(OpCodes.Ldarg_0);
    il.EmitCall(OpCodes.Call, getCity, null);
    il.Emit(OpCodes.Ret);
 
    return (Func<Address, String>)dm.CreateDelegate(typeof(Func<Address, String>));
}
 
var emitDelegate = GetEmitDelegate();
Run("Emit: run compiled statement", ()=>emitDelegate(address));

My guess is that using Emit is not something you will be doing a lot. But, we had to try. Again, executing a compiled expression was fast. But as with expressions, the problem comes when you have to compile before running.

Using Emit, create statement, compile it and run (39000 times slower than normal property access)

1

RunLong("Emit: Create statement, compile, run",()=>Emit(address));

As we can see, this is also horribly slow.

Conclusion

Unless you can create an expression/emit statement and compile it and then run the compiled version more than 200 times, in the app’s lifetime, using normal reflection is by far the preferred way to go when you have to dynamically invoke members on objects.

- Tore Vestues

Thanks to Åsmund Eldhuset.

Here’s the source

My talk titled “A Style of Programming”, was filmed and is already online.

You can find it here.

Most of the other talks from the conference can be found here.

- Tore Vestues

Xp2010 was a great event by the way, and you can find other talks here.

- Tore Vestues

Ndc 2010

I’m very proud to announce that I will be speaking at the Norwegian Developers Conference 2010 (track 6, day 3, 16:20).

My talk is named “A Style of programming”:

“This talk describes a set of coding principles that constitutes a style of programming that focuses on ease of coding, ease of changing the code, and ease of testing the code. The presentation aims at helping programmers understand how the principles relate to actual code. Every principle is made concrete through examples. This style of programming is influenced by leading object oriented and agile developers, and it is perfect for applying on object oriented languages such as C#.”

Hope to see you there!

- Tore Vestues

This is how I work with my source control system:

First, what do I check in? Logical chunks that work.

Then, how do I check it in?:

1. You start with no local changes (that’s the best way to start the day)
2. Get the latest source from the source control system.
3. At this point you want to be certain that not anyone else have broken anything, do one of the two:
• Have a build server that notifies when there is a check in, if the last check in was ok, then you’re good to go (this is by far the preferred way)
• Run the tests just after getting the latest source
4. Do what you came here for: code. Whenever you have a logical “chuck” of code, proceed to the next step.
5. You want to be certain that what you are about to check in is working: Run the unit tests one last time to make sure your code is working.
6. You have to merge your changes with anything else that might have changed: Get latest from the source control system.
7. Run the unit tests: At this point, you want to be certain that the combination of your code and the code from the repository is not failing anything. (Here it is a great advantage to have a build server that tells you that the source you are getting from the source control is working, so any failing tests you get now are guaranteed your fault)
8. Fix whatever is broken
9. check in (when all tests are green)
10. Repeat

Also note:

• On a general note, do your best not to check in failing code (failing tests, or even not compiling code). Failing code impeeds all the other team members. Don’t you get really annoyed when someone else on your team are messing up the source, and making lots of extra unnecceary work for you? I do not want to be that person.
• Do not, I repeat: do not, check in anything before getting the latest source. You want to make sure that all the latest source (not just yours) are working together.
• Do not wait too long to check in (to check in at least once a day is a good rule of thumb). The longer you wait, the more merging you will probably have to do.
• It is also a big advantage to have a build server that notifies if someone checks in failing code (so you do not have to be uncertain if it was you or someone else that broke the code when you get the latest source)

I am very interested in hearing your experiences with how to work with source control systems, feel free to post comments.

- Tore Vestues

I’m actively developing it. I’m also actively using it. In this post I’ll share my experience as a user of Glue, and how easy it is to set up the mappings using TDD.

The example

We want to create a mapping between DomainPerson and GuiPerson, listed here.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

public class DomainPerson
{
    public int Id { get; private set; }
    public String Name { get; set; }
    public DomainAddress Address { get; set; }
}
 
public class DomainAddress
{
    public String StreetAddress { get; set; }
    public int ZipCode { get; set; }
    public String City { get; set; }
    public String Country { get; set; }
}
 
public class GuiPerson
{
    public int Id { get { return 0;} set { return;} }
    public String Name { get; set; }
    public String StreetAddress { get; set; }
    public int ZipCode { get; set; }
    public String City { get; set; }
    public String Country { get; set; }
}

Making sure all properties are related

What I test first is that all the properties are related (or actively ignored). This makes it easy to later detect changes in the classes we map between. It also makes it easy for us to see what properties we have to handle.

But first, in traditional TDD style, lets start with writing a failing test. The test should verify that all properties on GuiPerson are either related or actively ignored. The test looks like this:

1
2
3
4
5

[Fact]
public void AsserAllPropertiesRelated()
{
	mapping.GetRelationsVerification().AssertAllPropertiesRelated<GuiPerson>();
}

and, as this will not compile, let’s create the actual mapping:

1

mapping = new Mapping<DomainPerson, GuiPerson>();

It compiles, but as expected, it fails. We have created a mapping, but nothing is related. A nice feature with Glue is that it tries to be as informative as possible when it fails. Look at the exception we receive when running this test:

Not all properties are related (or ignored): Id, Name, StreetAddress, ZipCode, City, Country

It tells us what properties we need to handle. This makes my job easy. I’ll just have to relate (or ignore) all the properties reported in the exception:

1
2
3
4
5
6
7

mapping.Relate(domain=>domain.Id,gui=>gui.Id);
mapping.Relate(domain => domain.Name, gui => gui.Name);
 
var addressMapping = new Mapping<DomainAddress, GuiPerson>();
addressMapping.AutoRelateEqualNames();
 
mapping.Flatten(domain=>domain.Address,addressMapping);

Running the test, I get another Exception:

Glue.GlueException : The relation between ‘Id’ and ‘Id’ has atleast one readonly property, and can not be related TwoWays

Ah, fair enough, it went a bit fast there. I related all properties, but I didn’t check if any where readonly. Luckily, Glue tells us this early. I’ll make this change:

1

mapping.RelateTowardsRight(domain => domain.Id, gui => gui.Id);

And when I run the test again, it goes green. Now all properties are related, and we are protected from future changes.

Make sure the mapping actually works

But will it really work? We can also easily check if the actual values can be set on the target object. You should do this. I always do. So, lets start with another test:

1
2
3
4
5

[Fact]
public void AssertMappingWorks()
{
    mapping.GetMapperVerification().AssertMapsCorrectlyTowards(new GuiPerson());
}

Running this test, we get an Exception:

Glue.GlueException : Failed properties: Id (Failed to set value)

Ah, it detected that Id on GuiPerson is totally unable to set. Ok, lets say that this is supposed to be this way. That means we should not map Id towards GuiPerson. That means that we must remove this:

1

mapping.RelateTowardsRight(domain => domain.Id, gui => gui.Id);

Running the tests again makes AssertMappingWorks gets green, but now AsserAllPropertiesRelated got red again. That is because we have not related Id on GuiPerson. But since we do not want to relate it, we ignore it, to signal that we actively have made that choice. We do it like this:

1

mapping.IgnoreTowards<GuiPerson>(gui=>gui.Id);

Running the tests, they both are green, and now we know that we have a working mapping, which also are protected from failing on future changes.

Note that this example only tests the mapping and relations towards GuiPerson, in a bidirectional mapping scenario I advice to write the same two tests towards DomainPerson.

This is how I do it, and it works great for me. Hope you liked it. To learn more about Glue, and to download it, go to the Glue homepage at Codeplex

- Tore Vestues