The User Object Test

Have you ever heard of code smells? Basically you can think of them as big red warning flags indicating deeper level issues or concerns with your code that aren’t always apparent at first sight.

I have never really had the good fortune as a professional developer to start work on a project that had had a good, clean, solid code base. Over the years after working on several projects like this I started to notice a trend that revolved around the data models that I like to call data model pollution. What I saw was that the data models contained data that was related but not essential or pertinent to the core of what that model was originally intended to be.

The easiest way to check this is to simply go take a look at your projects User Class. Most applications have users but if your project doesn’t then well I dunno. Try looking at some other class that was one of the first created or designed for you project. Snoop Lion formerly known as Snoop Dog might refer to one of these classes as an OG class.
Now that you have you user class open take a look at the properties and see if there is anything in there that’s out of place or odd. For example consider the properties of this interface for a user class:

interface IUser
string AccountNumber { get; set; }
Company Company { get; set; }
int CompanyId { get; set; }
string DepartmentName { get; set; }
bool DisplayWalkthrough { get; set; }
bool DisplayWalkthroughModal { get; set; }
string Email { get; set; }
string FirstName { get; set; }
string LastName { get; set; }
string FullName { get; set; }
ICollection FollowingMe { get; set; }
string JobTitle { get; set; }
DateTime LastLoginDate { get; set; }
string LocationName { get; set; }
string ManagerName { get; set; }
ICollection Notifications { get; set; }
string Picture { get; set; }
bool ReceiveCommentEmails { get; set; }
bool ReceiveCommentNotifications { get; set; }
bool ReceivePointsEmails { get; set; }
string Role { get; set; }
DateTime? StartDate { get; set; }
int Status { get; set; }
string UserName { get; set; }
User.UserStatusValue UserStatus { get; set; }

Looks a little funky right? I might consider FirstName, LastName, and JobTitle to be properties of a typical user object but what about DisplayWalkthrough, ReceivePointsEmails, and FollowingMe? Those extra properties have some relation to what a User should be but I would strongly argue that they are not pertinent to the core of what a User should be for the application this code belonged to.

I think over any period of time data model pollution is a natural occurrence that just happens as a side effect of fast feature delivery, code maintenance, and the natural evolution process of an application. As a project grows in size in complexity it becomes an enormous effort to avoid and prevent data model pollution from occurring. It just becomes down right impossible.

I believe the User Object Test is one indicator of something deeper and fundamentally wrong with all of the current enterprise application architecture patterns that exist today. I will delve deeper into this in my next blog.