Interesting post from Oren…‏


Boolean methods worry me because of their implications. If you have a Boolean method here, it means that somewhere else you have an if statement that works based on this method.

The “legacy” application I took ownership of when starting at my current employer is teeming with boolean methods – UserAccount as an example of this; IsSuspended, IsActive, IsAuthenticated etc. Funnily enough if I “Find Usages” they tend to have two types of usage; making decisions as to what to display in the UI, and validating whether an action can take place.

Oren hasn’t suggested his preferred approach to tackling this kind of problem but I would favour:

a) having these boolean methods moved out of my entity, and onto a view model for when I need this data when binding a view (my repositories can retrieve “suspended” or “not-suspended” users based on specifications).

b) when boolean properties (like IsActive) are used to determine whether or not to display a link to an action, based on the state of the domain (like  re-activate User for inactive accounts) then I’d prefer this responsibility to be delegated to to my application layer in a class responsible for application co-ordination, rather than having this logic my domain.

What do you think?


About craigcav

Craig Cavalier works as a Software Developer for Liquid Frameworks in Houston Tx, developing field ticketing and job management solutions for industrial field service companies.

Posted on June 13, 2009, in Uncategorized. Bookmark the permalink. Leave a comment.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: