Object-oriented design

[Camel]

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/

[Hitmen]

lol

[iago]

This first paragraph sounds really pretentious

I disagree -- it's not just the first paragraph. :P

[Hdx]

To be perfectly honest. I don't like most of your 'good code'.
Mainly due to the fact that there i so dammen much of it to do so dammen little.
But I think thats a personal opinion.
And yes I'm religiously against IDEs. I taker the same stance I do with religions.
I don't want to use them
I don't care if someone else uses them
They do have there strong points
They do have there weak points
I use them at times when I think it would be benificial to me.
I don't beleave I ever said I would refract something large without an IDE. But, refracting something is easy. It wouldn't be difficult to make a simple script that does it.
[/rant-reply]
~Hdx

[Camel]

To be perfectly honest. I don't like most of your 'good code'.
Mainly due to the fact that there i so dammen much of it to do so dammen little.

Can you give an example? If you're talking about what I think you are, your argument directly conflicts with OOD.

[edit] Also, I'm not trying to say my code is perfect or better than anyone else's code, I'm talking about programming theory. The XML class was just an example of the theory being applied.

I don't beleave I ever said I would refract something large without an IDE. But, refracting something is easy. It wouldn't be difficult to make a simple script that does it.

Refraction has to do with has to do with changing direction (usually, EM radiation); refactoring is the act of changing the name of a component in a computer program without changing its behavior.

Depending on the amount of reuse, it could be very easy or very difficult. Yesterday, I refactored a class in a library, and the clearcase plugin popped up and asked me to check out 300 files. If it wasn't for Eclipse, chances are good that I wouldn't have even realized the repercussions until my inbox was flooded from cron jobs failing with NoClassDefErrors.

[MyndFyre]

To be perfectly honest. I don't like most of your 'good code'.
Mainly due to the fact that there i so dammen much of it to do so dammen little.

Yep, sometimes that sucks. But, for those of us who program in the real world, we've already learned the hard way that a lot of boilerplate code produces more reliable software, more maintainable software, and more resilient software. That means, there is less likelihood of defects, it's easier to update, and when we make updates, there is a smaller chance something else will break.

@ Camel:
I didn't know it was called the Decorator Pattern before, bat I've used it. I also just created a Gadget for Microsoft in MVC written in JavaScript. We do all of our data object modeling in-house using a Factory-pattern approach.

You don't happen to live in Arizona, do you? We can always use another talented developer... :)

This is also kind of an aside, and an edit to the original post: I'm in graduate school right now pursuing an M.Eng in Software Engineering.  My first course is CSE 598 - Software Analysis and Design.  We're talking about UML modeling, what interfaces do, and the like.  GOOD thing that people are expected to know what a "polymorphic" method is.  Sheesh....

[Camel]

I've always thought the factory pattern was overused. For example, Java provides MD5 and SHA1 "Digest" classes through a factory, where you construct the Digest by telling the factory either "MD5" or "SHA1" - it's silly because the step of constructing the string is unnecessary.

I currently live in New Hampshire, but I'd be willing to relocate after my lease expires in six months, if it's really worth it. I just missed your IM because I was replying to this thread!

[edit]

x86/64] link=topic=10389.msg131809#msg131809 date=1191377118]
GOOD thing that people are expected to know what a "polymorphic" method is.  Sheesh....

What? Who doesn't know about polymorphism?

[Ender]

Yay for developer angst.

arrogance: yeah, yeah, it was there... ;) don't worry though: everyone on this forum is arrogant (except for maybe iago), even our token female! (who seems to have died...)

hibernate: My theory on frameworks like hibernate is that they're great in theory, but not as great in practice. In theory, IoC is better, but the time invested for injections via XML files counteracts this. However, there are times when they are useful. You should consider the fact that if the software engineers in a work environment all know a framework very well, it can very well drastically increase their productivity if they work on it, since there will be less dissent and more understanding regarding the design.

Oh, and last I heard, Spring is the framework all the Java freaks are raving about :P You should look into it if you haven't heard it already.

log4j: yeah, my thoughts are that logging is easy enough that you don't need a more comprehensive system

decorator: I always forget what this pattern means. Nice description.

factory: they're really great for the construction of a complicated object, especially one with a lot of error handling and other crap, since you can deal effectively isolate all the ugly code. That's why we made a religion forum. (just kidding :P)

interfaces: [interfaces are a way to link to the core] great way of describing them. yeah, they kick ass.

design pattern dangers: There's a danger of becoming too enamored with them. As the wise duffymo once said, design patterns breed too many "small boys with patterns syndrome." The danger is ruining the intuitive and tangible aspects of your objects by imposing unnatural patterns on them -- then the code becomes a confusing, unusable mess.

Sun Forums: You seem to be a big Java fan, so I'd suggest looking into the Sun Java forums. There's a really fun, active community there, with a core of very active experts. And yeah, most of them program in the real world (though I think this distinction is overrated :P) I don't really go on there anymore, but I did for a couple years.

[Camel]

design pattern dangers: There's a danger of becoming too enamored with them. As the wise duffymo once said, design patterns breed too many "small boys with patterns syndrome." The danger is ruining the intuitive and tangible aspects of your objects by imposing unnatural patterns on them -- then the code becomes a confusing, unusable mess.

Of course; everything in moderation. Design patterns can be used to simplify certain tasks, but you can't rely solely on them.

[while1]

So I spent the last hour or so reading up on the various design patterns.  At first when I skimmed the various design pattern names, a lot seemed alien and made me think "I have no idea wtf these design patterns are... I don't think I've ever implemented such before."  Then then after reading about them I realized that I have, but just didn't know that they were called by these names.