Derik Whittaker

Syndication

News


Images in this post missing? We recently lost them in a site migration. We're working to restore these as you read this. Should you need an image in an emergency, please contact us at imagehelp@codebetter.com
Object Construction – Constructing for Success

I have finally come to the conclusion that no object should be allowed to be constructed in any way that will allow for the object to be setup in an invalid state. 

Way too often I see an object that uses the empty constructor which then requires the user to ‘guess’ which properties are needed to setup the object correctly.  This in my opinion just leads to poor code and really hard to find bugs.  I would suggest that if an object needs certain values to be considered ‘valid’ then these values need to be provided during construction.

Imagine if you will you have an object; let’s call it the ‘Manager Object’.  In order for this object to be valid you need to provide it with the ‘ID’, ‘Name’ and ‘Authority Level’.  If you have an empty constructor, the users of the object must KNOW those values are needed.  If they don’t provide them very odd/subtle bugs may appear.

Now if your object’s constructor (or builder, factory, what ever) required those values at construction time no one would be able to build the object in an invalid state.  You could even go as far as asserting the values passed in to make sure they are within valid ranges.

By requiring your objects to be constructed in valid state at all times you will have more confidence in your app as well as a cleaner code base.  Oh, and by the way, the I would also suggest that the properties are read-only UNLESS EXPLICITLY needed for setting, this will also enforce a more stable object.

Finally, I know this seems way too obvious to many as simply best practice.  However just because it is obvious does not mean it is followed...... :(

 


Posted 05-04-2007 6:29 AM by Derik Whittaker
Filed under: ,

[Advertisement]

Comments

KG2V wrote re: Object Construction – Constructing for Success
on 05-04-2007 8:06 AM

I thought that was kinda obvious.  I think the first OOP book I read stated that on, oh, 20 years ago

A corollary:

If you have a set of propertys that must be validated as a set - DON'T use  setters - create a method that takes all of the values at onces, validates them, sets them internally, and returns success or falure.

Derik Whittaker wrote re: Object Construction – Constructing for Success
on 05-04-2007 8:20 AM

Agreed and understood.

But i have seen many, many examples where you construct an object then set all the properties one by one.  

This was my only point.

MadMaxPou wrote re: Object Construction – Constructing for Success
on 05-04-2007 8:56 AM

What about when you need to use XmlSerialization?  I believe that you need empty constructors for this feature to be available.

damieng wrote re: Object Construction – Constructing for Success
on 05-04-2007 8:56 AM

A prime example of this problem can be found in the .NET's HtmlControl namespace which contains various classes to

represent HTML tags.

The HTML specifications make it quite clear as to which attributes are required for a tag and therefore would be logical choices for the parameters on a constructor.

Not only is the default constructor present allowing you to create invalid HTML tags but there aren't even alternative constructors available.

So you end up with:

HtmlImage image = new HtmlImage();

image.Src = "/something.jpg";

which will happily write out illegal Html because the Alt attribute hasn't been specified.  It also makes building pages up in code overly verbose.

[)amien

Derik Whittaker wrote re: Object Construction – Constructing for Success
on 05-04-2007 9:00 AM

You are correct, I have not used this in a while so I did not think of this.  Not sure if it is possible, but if you could have a private constrcutor that is empty and still have the XmlSerialization work then that is the approach i would take.

Keep in mind, I am not saying that you should never have an empty constructor.  There are times/place for this.  I am only saying that if the object needs values to be considered 'in valid state' then you should have to provide those values at construction time.

Derik

Derik Whittaker wrote re: Object Construction – Constructing for Success
on 05-04-2007 9:03 AM

[)amien

In your example now imagine if you are a junior developer trying to fix a bug and the image.Src = "/something.jpg"; was missing.  

Here lies the problem.

Derik Whittaker wrote Object Construction - Constructing for Success - Part Duex
on 10-24-2007 10:07 AM

A few months ago I posted about my thoughts on Object Construction (found here ). In the post I talk

Daniel Gonzalez wrote re: Object Construction – Constructing for Success
on 10-26-2007 5:35 AM

I came to this post through your follow-up one, and saw a comment regarding default contructors for serialization/deserialization.

A good technique to keep people from using them is marking them with the ObsoleteAttribute. It won't prevent the object to be created but it will warn the developer at compile time (or Re-Sharper time) that they should not use that constructor.

regards

About The CodeBetter.Com Blog Network
CodeBetter.Com FAQ

Our Mission

Advertisers should contact Brendan

Subscribe
Google Reader or Homepage

del.icio.us CodeBetter.com Latest Items
Add to My Yahoo!
Subscribe with Bloglines
Subscribe in NewsGator Online
Subscribe with myFeedster
Add to My AOL
Furl CodeBetter.com Latest Items
Subscribe in Rojo

Member Projects
DimeCasts.Net - Derik Whittaker

Friends of Devlicio.us
Red-Gate Tools For SQL and .NET

NDepend

SlickEdit
 
SmartInspect .NET Logging
NGEDIT: ViEmu and Codekana
LiteAccounting.Com
DevExpress
Fixx
NHibernate Profiler
Unfuddle
Balsamiq Mockups
Scrumy
JetBrains - ReSharper
Umbraco
NServiceBus
RavenDb
Web Sequence Diagrams
Ducksboard<-- NEW Friend!

 



Site Copyright © 2007 CodeBetter.Com
Content Copyright Individual Bloggers

 

Community Server (Commercial Edition)