One of my colleagues comes to me, all excited about object initializers that were introduced in .NET 3.0 and I’m expected to be the critic. Probably because I always criticize bad use of new technology. However, this time the praises were justifiable. Not a surprise, he’s a clever guy.

“Because it makes code readable when initializing a large data structure”

Person person = new Person
{
    Firstname = "John",
    Lastname = "Doe",
    Address = new Address
    {
        StreetName = "Last Hope",
        Zip = 42,
        City = "Vladivostok"
    },
    PhoneNumbers = new string[]
    {
        "123-321",
        "+45 234 234",
        "3333333"
    }
};

I agree with him to 100% that this is very easy to read and understand, but I wonder what class it is that has responsibility of creating a whole object structure like this? When does he actually need it?

When a new technology arrives it is easy to forget why the old technology was there in the first place. Why do constructors exist and why are we not using the default constructor everywhere in our programs? I work with programs like that every day, and I’ve actually seen a recommendation to always add a default constructor to your objects for easier initialization.

Purpose of constructors

The purpose of the constructor is to initialize your instance of a class so it is ready to use. All dependencies of the class should be entered through the constructor so that you always get a valid object. If the class has no dependencies, you should add an empty constructor for easy initialization.

Consider the following entity

public class Person
{
    public int ID { get; set; }
    public string Firstname { get; set; }
    public string Lastname { get; set; }
}

Let’s say that ID is required to be set on the instance. This would certainly enable object initializers, but would it be a good practice? Let me purpose the following instead

public class Person
{
    private int id;

    public Person(int id)
    {
        System.Diagnostics.Debug.Assert(id > -1, "Class Person was initialized with ID < 0");
        this.id = id;
    }

    public int ID { get { return this.id; } }
    public string Firstname { get; set; }
    public string Lastname { get; set; }
}

Do you see what I just did? I killed object initialization in favour of encapsulation of parameter ID, and assertion of the value that is set. What we can learn from this is that the constructor also is a kind of interface of what dependencies a class has and this is very obvious when you’re dealing with IoC.

While my colleague agrees with me that classes should not be modified to enable object initializers, it is much more expressive than a large constructor with lots of parameters. Again I have to join him in this cause, that object initializers are easier to understand, but a large constructor is an obvious way of telling that this class has too much responsibilities and should be refactored.

Another concern about constructors are complicated initializations with objects feeding other objects through the constructor. You know what I mean if you’ve seen anything like this, an obvious indication that you need an IoC container in your project.

new ArticleFacade(new ArticleRepository(new ArticleValidator(), new ArticleDataAccess(Configuration.GetInstance().Database))));

Rounding it up

The use of object initializers may make your code more readable, but never change the interface of your model/objects to support it. If you need to use object initializers to make a heavy object structure readable you might consider using some sort of ObjectFactory instead, because your class that creates the structure obviously has too much responsibility.

Xml is another fantastic overlooked technology. Not because it’s one of the most used data formats in the world, but because almost all of those applications only use a tiny bit of the whole xml technology. It is really fantastic and it features some functionality that no other data format does.

<?xml version="1.0" encoding="utf-8" standalone="yes" ?>
<bookstore>
	<authors>
		<author id="janeausten">
			<firstname>Jane</firstname>
			<lastname>Austen</lastname>
		</author>
	</authors>
	<books>
		<book isbn="ISBN-9781853260001">
			<title>Pride and Prejudice</title>
			<authors-ref values="janeausten" />
			<price sek="79" />
			<plot><![CDATA[Pride and Prejudice is the story of Mr and Mrs Bennet (minor gentry), their five daughters, and the various romantic adventures at their Hertfordshire residence of Longbourn....]]></plot>
		</book>
	</books>
</bookstore>

I would not claim it to be a beautiful format. It is not very minimalistic and sending huge amounts of data as XML will cause a lot of overhead. But, anyone that ever done some HTML will get the idea from the start.

Document Type Definition

Included in the Xml suite is the DTD, document type definition. This is its own language that describes what the xml markup should look like. The xml markup is a sort of language, and the DTD setup the rules for this language.

<!ELEMENT bookstore (authors,books)>

<!-- AUTHORS -->
<!ELEMENT authors (author*)>
<!ELEMENT author (firstname,lastname)>
<!ATTLIST author id ID #REQUIRED>

<!ELEMENT firstname (#PCDATA)>
<!ELEMENT lastname (#PCDATA)>

<!-- BOOKS -->
<!ELEMENT books (book*)>
<!ELEMENT book (authors-ref,price,plot)>
<!ATTLIST book isbn ID #REQUIRED>

<!ELEMENT title (#PCDATA)>
<!ELEMENT authors-ref EMPTY>
<!ATTLIST authors-ref values IDREFS #REQUIRED>

<!ELEMENT price EMPTY>
<!ATTLIST price sek CDATA #IMPLIED>
<!ATTLIST price usd CDATA #IMPLIED>
<!ATTLIST price eur CDATA #IMPLIED>

<!ELEMENT plot (#PCDATA)>

A small DTD is very readable like this one, but it is easy to loose readability as the size of your document format grows.

DTDs are very useful when you want to exchange xml documents with others. You define a DTD that others have to follow, and when you recieve a document from them, you can validate it and make sure that it follows the specification, before you start using it. You can also specify indexes in your DTD which will make searching in your XML blazing fast.

XSD is a schema format that also specifies the XML format just like the DTD but in XML. It is a bit harder to define a XSD schema than a DTD, but the application feels more natural since it is written in XML and it is actually much more powerful. If I was going to implement XML validation I would always use XSD before DTD, but I would consider to use DTD when I need to communicate the XML data format to the customer because of its readability.

<?xml version="1.0" encoding="utf-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns="http://mint.litemedia.se" targetNamespace="http://mint.litemedia.se" elementFormDefault="qualified">

	<!-- ROOT ELEMENT -->
	<xs:element name="bookstore">
		<xs:complexType>
			<xs:sequence>
				<xs:element name="authors">
					<xs:complexType>
						<xs:sequence>
							<xs:element name="author" type="author" maxOccurs="unbounded">
							</xs:element>
						</xs:sequence>
					</xs:complexType>
				</xs:element>
				<xs:element name="books">
					<xs:complexType>
						<xs:sequence>
							<xs:element name="book" type="book" maxOccurs="unbounded">
							</xs:element>
						</xs:sequence>
					</xs:complexType>
				</xs:element>
			</xs:sequence>
		</xs:complexType>

		<!-- KEYS -->
		<xs:keyref name="author-ref" refer="author-id">
			<xs:selector xpath="books/book/author-ref"/>
			<xs:field xpath="@values"/>
		</xs:keyref>

		<xs:unique  name="author-id">
			<xs:selector xpath="authors/author"/>
			<xs:field xpath="@id"/>
		</xs:unique>

		<xs:unique name="book-isbn">
			<xs:selector xpath="books/book"/>
			<xs:field xpath="@isbn"/>
		</xs:unique>
	</xs:element>

	<!-- AUTHOR TYPE -->
	<xs:complexType name="author">
		<xs:all>
			<xs:element name="firstname" type="xs:string"/>
			<xs:element name="lastname" type="xs:string"/>
		</xs:all>
		<xs:attribute name="id" type="xs:string" use="required"/>
	</xs:complexType>

	<!-- BOOK TYPE -->
	<xs:complexType name="book">
		<xs:sequence>
			<xs:element name="title" type="xs:string"/>
			<xs:element name="authors-ref">
				<xs:complexType>
					<xs:attribute name="values" type="xs:string"/>
				</xs:complexType>
			</xs:element>
			<xs:element name="price">
				<xs:complexType>
					<xs:attribute name="sek" type="xs:positiveInteger"/>
				</xs:complexType>
			</xs:element>
			<xs:element name="plot">
				<xs:simpleType>
					<xs:restriction base="xs:string">
						<xs:whiteSpace value="preserve"/>
					</xs:restriction>
				</xs:simpleType>
			</xs:element>
		</xs:sequence>
		<xs:attribute name="isbn">
			<xs:simpleType>
				<xs:restriction base="xs:string">
					<xs:pattern value="ISBN-[\d]*"/>
				</xs:restriction>
			</xs:simpleType>
		</xs:attribute>
	</xs:complexType>
</xs:schema>

When I create a schema for a bookstore I have defined what my data should look like, to me and to others that are going to talk to my system. So, when another developer comes along we can give him the data definition and tell him that this is the dataformat we support.

XSL Transformation

I remember a couple of years ago when everyone should learn HTML to “program” homepages. Lots of pages emerged about pets, families and obscure hobbies. That was the flower power time of the internet. The next big thing would be XML as a backbone to the XSLT transformation. XML would serve as a data bearer only, and the client browser would use a stylesheet to render the HTML. This enabled different rendering for different devices and moving all rendering from server side to client side. This was a genious idea from W3C but it never got the attention that it deserved. I think it was way ahead of its time. When the low grade teacher just’ve learnt HTML she was going to grasp seperation of concerns and a deviation between data storage and presentation? That was a bit too much to ask. The real programmers didn’t grasp the technology because this was evolutionary thinking by the time and they were still struggling with CSS. There were no real tool that made it simple to understand the relationship between XML/XSL, so the whole technology was pretty much forgotten.

Today, seperation of concerns, rendering of strict xhtml and accessability for different devices are on everyones lips but XSL transformation have never found the way back to the web. Instead we use it for more obscure transformations in the backend.

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="2.0"
				xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
				xmlns:fo="http://www.w3.org/1999/XSL/Format"
				xmlns:xs="http://www.w3.org/2001/XMLSchema"
				xmlns:fn="http://www.w3.org/2005/xpath-functions"
				xmlns:mint="http://mint.litemedia.se">

	<xsl:output encoding="utf-8" indent="yes" method="xhtml" />
	<xsl:output doctype-system="http://www.w3c.org/tr/html4/strict.dtd"/>
	<xsl:output doctype-public="-//W3c//DTD HTML 4.01//EN"/> 

	<xsl:template match="/">
		<html>
			<head>
				<title>Bookstore</title>
				<link rel="stylesheet" href="style.css" type="text/css" media="screen" />
			</head>
			<body>
				<h1>Bookstore</h1>
				<ul class="books">
					<xsl:apply-templates select="/mint:bookstore/mint:books/*" />
				</ul>
			</body>
		</html>
	</xsl:template>

	<xsl:template match="mint:book">
		<li class="book">
			<h2><xsl:value-of select="mint:title"/></h2>
			<em>by</em><xsl:value-of select="id(mint:authors-ref/@values)" />
			<p>
				Plot: <xsl:value-of select="mint:plot" />
			</p>
		</li>
	</xsl:template>
</xsl:stylesheet>

Open this link in Internet Explorer for result

With the power of XSLT you can transform any XML document to anything at all. A simple XML language will let you query your data, format it and sort. The number of built in functions are minimal so that you can expand them with your own library by adding namespaces to the transformation engine.

As I said, the XSLT technology is as useful today as when it arrived. Ponder that you in your C# application needs to output your object domain into a CSV format. This is a trivial thing when using XSLT. First you use the built in XmlSerializer to get your data as XML, and then you write your XSLT so that you get the data in the order that you want. When the requirements on this data changes you only have to update your XSLT script and not change any compiled logic.

Another cool thing in .NET is the implementation of XmlReader. Any data structure that can be interpreted as a DOM can be readed as XML and transformed to anything you like using XSLT on the fly. All you need to do is to implement your own XmlReader. Imagine reading that csv file as if it were XML and query it with XPATH using something like /item[@id='1234'] instead of your own custom made search logic.

From here and on

There are more XML technologies. Some are quite cool, some have been forgotten. Some you won’t understand until you’ve tried them. Here are my favourites.

• XHtml
• XPath
• XForms
• XLink

Also make sure that you check out all the cool stuff you can do with XML in the .NET Framework including Linq to XML. Knowing this is like knowing your backyard and knowledge like this may get you safely out of pretty nasty requirements in the future.

Download source example

Yesterday I held a one hour seminar about unit testing with Rhino Mocks. It was the last in a series of seminars about unit testing that I’ve been having in order to get everyone up to date. Today I’ve been preparing this blog post about that seminar, but as I was reading through articles on Rhino Mocks I found an alternative syntax that was made available in version 3.5.

In unit testing you most often test state or return values, because this is the easiest thing to do. You test if a function returns the expected value or if a property was set to the value you anticipated. However, sometimes you’re more interested the behaviour of a function than the state it delivers.

Study the following SUT

public class ArticleRepository
{
    private IDataAccess<Article> dataAccess;
    private IValidate<Article> validator;

    public ArticleRepository(IDataAccess<Article> dataAccess, IValidate<Article> validator)
    {
        this.dataAccess = dataAccess;
        this.validator = validator;
    }

    public void Save(Article article)
    {
        // If validation is success, save article
        if (validator.Validate(article))
            dataAccess.Save(article);
    }
}

The repository will use the DataAccess class to persist the article if the article validates. This is a pretty common scenario.

What you’re interested in here is to test that dataAccess.Save(article) is only called if article passed validation. You could do this by looking at the result of Save in the database, but I would call that integration testing, and not really unit testing.

Instead we test the behaviour of Save, and this we can do with Rhino Mocks.

[Test(Description = "Should save if article validates")]
public void ShouldSaveIfArticleValidates()
{
    /* Setup */
    MockRepository mocks = new MockRepository();
    IDataAccess<Article> dataAccess = mocks.StrictMock<IDataAccess<Article>>();
    IValidate<Article> validator = mocks.StrictMock<IValidate<Article>>();

    // SUT
    ArticleRepository repository = new ArticleRepository(dataAccess, validator);

    // Test data
    Article article = new Article("My test article");

    With.Mocks(mocks).Expecting(delegate
    {
        /* Record */
        Expect.Call(validator.Validate(article)).Return(true);
        Expect.Call(() => dataAccess.Save(article));
    })
    .Verify(delegate
    {
        /* Replay */
        repository.Save(article);
    });
}

In Rhino Mocks you first record the behaviour that you expect. In this case I expect that validation will be called, and I would prefer if that returns true. After that I expect the Save method on dataAccess to be called.

When I’ve set my expectations I will verify by running the SUT. If my expectations are not met the test will fail with an exception. If any other methods are called except what I’ve specified in my expectations, the test will fail. This is the behaviour of strict mock, and this is the anti-pattern of overspecified tests.

Anti-pattern: Overspecified test
When even the slightest change in SUT will make tests break, even though the test description is still true.

In this case I might want to add some revision history to my article and enable check in/check out functionality. Before the article is saved it should be checked in. This would however fail the test above because every call to dataAccess would need to be registered as an expectation (because this is a strict mock).

Once I had a project with a couple of hundreds of tests like this. Every small change to the SUT would make half of them to fail even though they still were true. They only needed something more to be expected.

The solution to this is the dynamic mock and there is a whole new syntax in Rhino Mocks 3.5 around this problem. The recording and replaying of expectations are still there, but it is hidden in an AAA (Arrange, Act, Assert) syntax.

[Test(Description="Should not call save when validation fails")]
public void ShouldNotCallSaveWhenValidationFails()
{
    /* Setup */
    IDataAccess<Article> dataAccess = MockRepository.GenerateMock<IDataAccess<Article>>();
    IValidate<Article> validator = MockRepository.GenerateMock<IValidate<Article>>();

    Article article = new Article("My new article");

    /* Arrange */
    validator.Expect(va => va.Validate(article)).Return(false);

    /* Act */
    new ArticleRepository(dataAccess, validator).Save(article);

    /* Assert */
    dataAccess.AssertWasNotCalled(da => da.Save(article));
}

This takes full advantage of extension methods that were introduced in .NET 3.0. AssertWasNotCalled is an extension method that verifies that da.Save(article) was never called.

I read a rule once that your unit test should never be more than 10 statements, because that would indicate the test is too complex (which indicates that your SUT is too complex). With this new syntax I might be able to stick to that rule even when I’m doing behaviour testing.

Thank you Ayende.

There are not many job titles in this line of business if you start sorting out the fake ones. We have our project managers and developers. Apart from that most positions in the development team are developers with different set of skills. A tester is a developer with testing skills. An art director is a developer with a pen and paper, and a user experience expert is also a wierd kind of developer. A developer is simply someone with a craft that will result in a system. All those in the development team are craftsmen at their line of work and also developers (except the project manager who is only shouting for status every 15 minutes, but doesn’t really contribute to the actual crafting – no hard feelings, we love you anyway).

What bugs me right now are the architects, because I don’t know what their special skillset are. What do they know that we don’t? Nothing really, because an architect in the IT industry is probably

• A promoted developer
• Self-proclaimed title

Most common is the promoted developer that receives the title architect for long and faithful service to the company. He will continue to work with the same tasks as before, but with a new title and higher salary. This is also a way to get the very attractive developers to stay in the company.

The worst are the self proclaimed architects. They become architects between two jobs because they think they’ve been working with software development long enough and have the experience required for an architect. Often they like to boast about their title and tell others about bad design desicions they made, even if they don’t have a clue.

It has become like this because none really know what an architect is or is supposed to be. They don’t know what tasks are given to an architect and for most people in the IT industry, “architect” is just a synonym for “senior developer”.

It is not like the nurse or the surgeon. I don’t suppose that anyone would promote a nurse to a surgeon because of long service, or that a nurse would proclaim to be a surgeon when she applies for a new job. This is because there is a distinct set of knowledge a surgeon has that the nurse must learn to enable advancement. In the same way I would claim that there is a certain amount of knowledge a developer must face to call themselves “architect”.

This is what I think defines an architect

• An expert in design patterns
• Master of many languages
• Broad architectual mindset
• Full insight in all current methodologies
• In the forefront of new technology
• Master of quality

I also think that an architect should

• Write a blog about his work
• Read a technical book every month
• Learn a new language every year
• Hold seminars where he share knowledge
• Go to conferences regularly

The difference between an architect and a senior developer is that an architect is not doing active software development in one project. He is assigned to many projects, to help out with his expertise and to guide the developers through hard architectual design issues. He is there to enforce high quality and to guide the development team in new technologies and methodologies.

To the company, the architect is the person that makes hard projects safe, and eliminates risk. He is the one that find the best solution to the real customer problem, both technically and in terms of functionality. The architect is the link between the customer and the high risk, high stakes to make it comfortable, and he is a comfort to the developers.

This is what an architect is in my mind, and I would be very delighted to meet one.

(* As a side note, I view myself as a junior developer with high sense of quality. I lack alot of experience and I learn new things every day. I know that my collegues sometimes see me as a mr KnowItAll, but I hope that they can forgive my enthusiasm and burning heart to share every piece of knowledge that I have, and just accept me for what I am – a coding ninja nerd)