TDD and Object Development
When using TDD practices, you may think ahead a little bit to a situation in the future. For instance, suppose you have this:
public class CustomerClassification
{
public CustomerClassification(string name, string type)
{
this.Name = name;
this.Type = type;
}
public string Name
{
get { return _name; }
set { _name = value; }
}
public string Type
{
get { return _type; }
set { _type = value; }
}
}
It's tempting to think that the property values will need to be change for some reason in the future, even though your current tests and current development of the application don't identify a need for a setter. I'd recommend that you leave out the setter until you actually see a need for adding it in. The reason is that this is more inline with TDD (implement it only when you need it), plus setters may cause problems in the future (changing values that shouldn't be changed as the constructor would be the only point of entry).
A perspective in the light of TDD... this may not always be a valid reason and I'm definitely not against setters,but it's something to consider.