Re: HOWTO use a Factory
"Alf P. Steinbach" <firstname.lastname@example.org> wrote in
However, you might and should probably consider introducing a class
ValidXXX that represents valid strings of whatever the format is.
Then the failure to validate can be detected as near to the source of
the string as possibly (by having /that/ class' constructor throw),
and valid strings can then be passed around as ValidXXX instances with
no need to check them everywhere for validity: you know they're valid.
This general principle of not passing possibly invalid data around
tends to simplify code enormously, thus also reducing the number of
And it's very very closely tied in with the concept of throwing from
constructors, so that you know that if you have an object at hand,
then that is perforce a /valid/ object with some class invariant
I have to strongly agree with this. :) I find it best to validate data
coming into the application as early as possible. For one thing, it
makes it easier to pinpoint where the problem originates and reprompt
the user if necessary for valid data. It also allows you to assume
correctness for the rest of the application (at least in release builds,
you might want some asserts here and there to validate assumptions about
the data that are active in debug/development builds.).
Another thing that comes to mind... You didn't mention whether this
data comes from the user or another programmer on the team. If it's the
later, then you may just want to validate in debug builds and make the
programmer fix his erroneous code rather than go through a possibly
expensive validation process all the time. In other words, some design
choices vary depending upon the target audience. For example, we would
all hate it if the STL did too much parameter validation each time we
tried to use it.