Disclaimer: This first paragraph sounds really pretentious, but if you read the whole post I think you'll agree with me that I am well justified.
When I talk about OO program design with people who have not actually taken OOA/D classes, I always end up feeling like I'm preaching to a crowd of people who think they know what OOD is about, but actually are clueless. The first thing you learn in such a class is that ninety percent of OO code is OO crap. The reasoning is simple, but is not easy for most to grasp. In order to fully understand why, you have to learn how to take full advantage of your OO framework.
I've done a lot of Java/.NET work in the past few years, and to date I haven't met in the workplace a single professional OO developer who knew what a design pattern is. This is arguably the single most fundamental thing that should absolutely be a requirement for anyone to call themselves an object-oriented developer! To put it very simply, a design pattern is a solution to a problem. A better definition would be a
good solution to a
common problem. An even better definition would be a
reusable good solution to a common
non-trivial problem.
If you aren't familiar with the Decorator design pattern, read
this (or at least look at the example) before continuing.
A couple of weeks ago, I ran across a situation where I needed to parse an XML file in to a structure in memory. I hadn't done this since I had my first job, and I had to do the same task in pure C - I was in pointer hell, and I didn't even have a package to parse the XML out for me. Armed with my knowledge of the Decorator design pattern, I now considered the task trivial. The XML file is a hierarchy of "XML Elements," beginning with a root node, where each node can contain between zero and infinite number of children. An even better description would be:
XML File: a text file containing exactly one XML Element, whose parent is NULL
XML Element: a thing with a name, a parent XML Element, and either a value or children
This simple description works well in combination with org.xml.sax.XMLReader, because it parses through an XML file and calls methods like startElement() and endElement() as it finds them in the file, allowing a decorator pattern to
decorate the tree as the file is parsed. Take a quick look at my
class to see how I did it.
Earlier today, I got an IM from a member of this forum (who shall remain nameless) in regards to the XMLElementDecorator class I posted - they wanted me to consider renaming the class to something that described the class. I was furious! Not because someone was dissatisfied with my work, but at the ignorance of someone whom I thought would know better. If you still think my class name is anything less than
perfectly descriptive, please explain why.
And now, since I still haven't fallen asleep, I'll continue to rant about things that annoy me.
One of my biggest pet-peeve about OOD is people's inability to understand interfaces. In my bot, I have an interface called EventHandler. Something that implements my EventHandler interface can link in to my core package and -- gasp -- handle battle.net events. This can also be called a
fucking plugin. Three separate people have confrotnted me to describe the interface as "useless," because they didn't understand the wealth of simplicity it affords for a plugin framework. Of these three people, I successfully got the message across to only one of them; one of the remaining two was not familiar with object-oriented programming (which is forgiveable), and the other was just a flat-out moron.
Another of my pet-peves: people who
religiously oppose IDEs. I love makefiles, and I promise I'll use them in every C/C++ project I ever work on. But come on, Java developers; get with the program. Stop clinging to your console security blanket, and look at what Eclipse has to offer. Hdx actually told me one day that he'd rather manually move .java files, edit the package line, and update all references to the class than right click/refactor/rename in Eclipse. Hey, I can't force you to do anything, but I use Java in the real world, and I don't have six months to change the package my classes are in. If Eclipse wasn't an editor -- even if the only feature it had was refactoring, I'd still use it.
Another big one: people who use log4j, and people who contributed to the log4j project. You people have successfully written egregious bloatwear, and you try to cover it up with falsified benchmarks. [rant]Your package is not on par with System.out.println() the way you claim it is because that's the method you call when you're done dicking around with the strings. Your package's only feature is that it's easy to a logging object to a class. Every day that I go to work, I have to read through about 80 emails from cron to make sure my nightly scripts were sucessful because I couldn't disable a WARNING! Here's a tip: delete your entire code-base - yeah, the entire thing. Replace it with the Out class I posted on this forum; it has every feature log4j does, and it's not a PITA to turn off logging for individual classes because it has the remarkable ability to add keys that don't exist to the settings file.[/rant]
And, to date, the biggest one of all: hibernate. They use the concept of POJOs - it stands for "plain old java objects." For each table in your database, you create a java class (a POJO) with an instance variable for each field. You then write an XML file to link the POJO to the database, and the hibernate framework will load up an absurd number of objects to do even the most trivial of tasks. I've never seen such a poor use of reflection before. My boss tried very hard to get me to use Hibernate to write a tool about six months ago; I pulled him in to a conference room, and in forty minutes, I showed how the entire package could be subverted without changing a single line of the actual program; by only changing the POJOs to extend a class I wrote in an email rant in Outlook -- which incidentally worked flawlessly the first time I pasted it in to Eclipse. Take a look at how I implemented the database in my bot, because it uses some of the same principles, although the FOREIGN KEYs aren't represented by an object-to-object link the way the are at work:
http://bnubot.googlecode.com/svn/trunk/BNUBot/src/net/bnubot/bot/database/
