Monthly Archives: June 2009
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?