We coders can't even keep track of a few primitives. Can we just accept that and adjust our style or do we want to continue obsessing over primitive obsession?
UML example of taking what might be primitive types (Contact and SocialSecurity as string, in this case) and removing the primitive and substituting it with a user-defined type
publicclassCustomer{publicstring Name {get;privateset;}publicstring Email {get;privateset;}publicCustomer(string name,string email){// Validate nameif(string.IsNullOrWhiteSpace(name)|| name.Length >50)thrownewArgumentException("Name is invalid");// Validate e-mailif(string.IsNullOrWhiteSpace(email)|| email.Length >100)thrownewArgumentException("E-mail is invalid");if(!Regex.IsMatch(email,@"^([\w\.\-]+)@([\w\-]+)((\.(\w){2,3})+)$"))thrownewArgumentException("E-mail is invalid");
Name = name;
Email = email;}publicvoidChangeName(string name){// Validate nameif(string.IsNullOrWhiteSpace(name)|| name.Length >50)thrownewArgumentException("Name is invalid");
Name = name;}publicvoidChangeEmail(string email){// Validate e-mailif(string.IsNullOrWhiteSpace(email)|| email.Length >100)thrownewArgumentException("E-mail is invalid");if(!Regex.IsMatch(email,@"^([\w\.\-]+)@([\w\-]+)((\.(\w){2,3})+)$"))thrownewArgumentException("E-mail is invalid");
Email = email;}}
The author says that you can't keep using primitives! Your validation code will end up being duplicated and scattered all over the architecture! Well? Yes and no. It depends on what kind of architecture you're building. DRY can be a very bad thing in one scenario and absolutely necessary in another. Don't use a LOTR architecture strategy if you don't need to