Good name for the settingJonah Bron wrote: I definitely agree that the developer should be able to change the century threshold.
Thanks and yes. There is a school of thought that says every object must either have an "identity" or be a value object, but I don't know if there is a strict definition, but basically yes.Jonah Bron wrote:This object is also good at simply containing this data. Would this be an implementation of the Value Object pattern?
In TDD it is more important to get it working first (tests passing). The goal is to write code that solves the user's problem, and minimize time writing code that does not directly solve the problem at hand. The next goal is to make that code "solid", it shouldn't break when programmers use it wrong, it should have error handling (exceptions). "Get it working first". Commit that to SVNJonah Bron wrote:One question. Why do you break up the range every time the validity is checked, instead of just once in the constructor? Also, why do you check the validity every time the range is accessed, instead of just setting a boolean variable?
Once that is done the next most important goal is code readability, get the code re-factored. This produces maintainable code. Commit the cleanups to SVN. At this point our code can seem to be really inefficient compared to a procedural implementation. Often times this doesn't even create bottlenecks, and is often cited as a down side to readable code in general, it can be inefficient. However with TDD, I can add the caching on at a later date, where as if I had focused on the caching before the business logic, the main code would not be as readable in my opinion. Software is infinitely malleable (at least when doing TDD)