But then there are also programming perversions that are simply beyond good and evil (similar to the ones posted on The Daily WTF). Let me give you two examples - coincidentally each of those came from German vendors...
Case #1:
Java AWT UI (yes, the old days...), card layout, so there is one form visible at a time and the other forms are sent to the back. Now those UI classes need to exchange data, and this was achieved by putting all data into protected static variables in the base class, so that all derived classes could access it. Beautiful, isn't it? But that's not the whole story. Those static variables weren't business objects in the common sense - they were plain stupid string arrays. One array for each business object attribute (and of course, each datatype was represented by a string), and the actual "object" was identified by the array index. You know, something like this:
protected static String[] employeeFirstName;
protected static String[] employeeLastName;
protected static String[] employeeIncome;
protected static int currentEmployee;The memory alone still makes me shudder today...
Case #2:
Years later, this time we talk about a .NET WinForms application. Somehow the development lead had heard that it's a good idea to separate visualization from business model, so he invented two kinds of classes: UI classes and business object classes. Doesn't sound too bad? Well, first of all he kind of forgot about the third layer (data access, that's it!), and spilled his SQL statements all over his business objects. And by that I don't mean that you could read your SQL statement in clear text. No, they were created by a bizarre concatenated mechanism, which included the concept of putting some parts of the SQL code in base classes (re-use, you know), and distribute the rest over property getters within the derived classes. And this SQL code did not only cover business-relevant logic, it was also responsible for populating completely unrelated UI controls. The so called "business object" also contained information about which grid row or which tab page had been selected by the user - yeah, talking about interpretating another OO concept completely wrong. The Model-View-Controller design pattern is all about loose coupling, so that models can be applied with different views.
Uuuh, I try to repress the thought about it, but it keeps coming back...
For a developer, being able to start a project without this kind of legacy burden is a blessing. I appreciate it each time management decides to trust its own people to build up something from scratch, instead of buying in third party garbage like that.