This post originated from an RSS feed registered with .NET Buzz by Raymond Lewallen. Original Post: Avoid breaking your API - pay attention to your constructors. Feed Title: Raymond Lewallen Feed URL: /error.htm?aspxerrorpath=/blogs/raymond.lewallen/rss.aspx Feed Description: Patterns and Practices, OOP, .Net and Sql Latest .NET Buzz Posts Latest .NET Buzz Posts by Raymond Lewallen Latest Posts From Raymond Lewallen

I was playing with a document coverter API a few months ago to do some PDF to Word conversions.  I had some code already built into a console app to use that version and it was working fine.  Last night I went and downloaded their latest version, and wouldn’t you know, it commited one of the major crimes of APIs: it broke my code.

The culprit?  The constructor to a class.  It used to work as follows:

Converter fileConverter = new Converter();
fileConverter.Path = “c:\myfiles\test.pdf”;

Now, for whatever reason, they decided to change the functionality so that you pass the file path into the constructor like so:

Converter fileConverter = new Converter(filePath);

Now, there is nothing wrong with this, except for one major thing they overlooked.  On a class, if you have a parameterized contructor, the comiler WILL NOT emit a default parameterless constructor.  Only when the class is void of any constructor at all will the compiler emit a default parameterless constructor.  When they created the parameterized constructor, they should have put in another constructor so that breaking changes wouldn’t occur:

public Converter() {}

The Path property is still read/write, so simply adding the parameterless constructor would have left my code working fine.  Please, avoid the same mistake.  This would have avoided them shipping their API with breaking changes and help them to avoid some pissed off customers who rely on their product.