It is 4th July today. after watching fireworks at Columbus downtown last night and pressure washing my patio and side walk in the morning, I got to sit in front of my PC.
Yes, it is July now, it is the time for Anti-pattern for July.
This is how it goes.
The title of the anti-pattern is : Flags Over Objects
The subtitle is : So easy you can add another twenty options
The elaboration for the anti-pattern is: instead of using objects, Polymorphism, or delegation, a flag is added to the class and exposed for public consumption. this often leads to many flags being added in lieu of more maintainable code.
The quote is “ The best thing about a Boolean is that even you are wrong, you are only a bit off”
The link to the anti-pattern is
http://deviq.com/flags-over-objects
The Flags Over Objects anti-pattern occurs when behavior is written outside of an object
by inspecting flags (such as status codes), rather than within the object itself. This violates the Tell, Don't Ask principle, and results in chatty interfaces and distribution of behavior that probably belongs within the object. Working around this issue,
one will often experience the Shotgun Surgery coding smell, in which many small changes to many files are required in order to make changes to the system.
There are many ways to address this anti-pattern. In the worst cases, the State
design pattern can effectively be used to bring all state-transition related behavior into the object, or at least into objects specifically constructed to handle the responsibility
of state and state transitions.
Take an example, if you see one class (Transaction Business Entity) representing many business transactions and a flag (Transaction Type) as a public accessible property indicting which business transaction it is, you are in front of “flag over objects” anti-pattern.
it seams intuitive and easy to have this type design when you add first flag to the class. but before you realized you will be attempted to added more and more. on the other end, you will have many places making logic decisions based on the value of the flags. that is where the bad smell comes out. First of all, these conditional logic are all over the places ( outside the class), secondly, it is more than likely they got repeated in different places. it is commonly recognized that code in that nature is difficult to debug, difficult to change. Due to large number of conditional logic, the cyclomatic complexity of the codebase will go no way but high.
On the other hand, one of the characteristics of OOP is lack of conditional logic. When new business transaction types are added to the codebase, instead of introducing flags or switches, sub-class, interface or delegation are used, in the beginning it could be seen as lots of more work as comparing to using flags. but the effort spent on proper OOP design will pay back in the long run. I promise you, your successors will sure thank you for handling them more maintainable codebase…
So the proper pattern is : Object over flag. whenever you see a flag or a enum type of property, you ask yourself, is this indicating the same thing with different characteristic or different thing all together. if the answer is the second one, you are highly encouraged to consider other OOP technics like objects, Polymorphism, or delegation in lieu of the flags.
Take an example, if you see one class (Transaction Business Entity) representing many business transactions and a flag (Transaction Type) as a public accessible property indicting which business transaction it is, you are in front of “flag over objects” anti-pattern.
it seams intuitive and easy to have this type design when you add first flag to the class. but before you realized you will be attempted to added more and more. on the other end, you will have many places making logic decisions based on the value of the flags. that is where the bad smell comes out. First of all, these conditional logic are all over the places ( outside the class), secondly, it is more than likely they got repeated in different places. it is commonly recognized that code in that nature is difficult to debug, difficult to change. Due to large number of conditional logic, the cyclomatic complexity of the codebase will go no way but high.
On the other hand, one of the characteristics of OOP is lack of conditional logic. When new business transaction types are added to the codebase, instead of introducing flags or switches, sub-class, interface or delegation are used, in the beginning it could be seen as lots of more work as comparing to using flags. but the effort spent on proper OOP design will pay back in the long run. I promise you, your successors will sure thank you for handling them more maintainable codebase…
So the proper pattern is : Object over flag. whenever you see a flag or a enum type of property, you ask yourself, is this indicating the same thing with different characteristic or different thing all together. if the answer is the second one, you are highly encouraged to consider other OOP technics like objects, Polymorphism, or delegation in lieu of the flags.
