your 2010 program would need to hold data pertaining to your 2010 needs, say number of days, weeks, months, years. It would need specific functions to calculate these. These are your fields and methods. So you can have a 2010 class to deal with 2010 data. If you need a function to convert days to weeks, for instance, that can be made into a universal helper function - either make it public so that you include 2010 in other projects, make it static and just refer to it without instantiating a 2010 object or stick it in a helper class like MyHelperClass (this could lead to a jumble up too.) Classes should be loosely coupled with as tight cohesion as possible.
If you're going to write many 2010-related programs/versions, then you would want a template class to derive from. Then you start looking at abstract classes and interfaces (I'm not sure if C++ draws a distinction between the two) and use inheritance.
You can use design patterns when your 2010-class starts getting complex and you want to simplify maintenance. I must just say, from reading pretentious comments in the social forums, that design patterns are merely an aid to solving a type of problem and should not be over-used. It allows one to stand on the shoulders of giants when designing a complex solution and shouldn't make the solution unnecassarily complex.