Skip to main content



Under or over-engineering?

Whenever you see classes called controler, provider, decider, manager, presenter, etc. which reassembles to some managerial job, you know that it isn't truly object oriented. It is actually procedural way of thinking, just packed in classes. I just saw a class called ColorDecider, which has one public method, two private ones and no state at all. The only job of this class is to decide which color should be chosen based on the state of some other object. It is actually a replacement for a switch or dictionary in that object. It does the same job, but it looks smarter. Not for me. But it has an interface, because it is nice thing to have. There are no other classes which implement this interface, because there can be only one way of presenting data in the system in one time, and it is defined by requirements. This behavior will be changed only if requirements change one day. So, why it needs a whole class?

Latest Posts

A Cross-Thread Exception in DevExpress XPO


PST Data Structure View Tool

Use embedded IE in FHP to show Office documents

PIA for Office 2007 and VSTO 3.0 Improvements

Security and FHP

Hosted control in FHP

New Explorers and Inspectors

ItemRemove Event in Outlook 2003

ItemAdd Event