Object Obsession

Recently I talked to a colleague who considered switching jobs but he wasn't so successful at his interview. "Man, it was hard." "How so?"

"OO concept: What's the difference between aggregation and composition?"

Yikes I am stumped. Just when do these terms come to play in real life? I vaguedly remember these things in some academic materials. Big words, perhaps buzz words. Do these things actually help you write working, maintainable programs?

Both words suggest a "has-a" relationship, but what is the difference?

See this link for detailed discussion: http://faq.javaranch.com/view?AssociationVsAggregationVsComposition.

Composition describes object that compose of important parts you can't live without. Like a car is not a car anymore without an engine. Association is a weaker description, like a tree is still a tree without some branch.

"How do you test an EJB?"

We don't use EJBs all that much here at work. Code wise, EJB2 is quite messy. It is very hard to write that code without a code generator like Websphere. However mess it is, how do you test it? of course you deploy it and try running the methods within! Nope, not good answer. The answer people look for is of course JUnit, specifically JUnit EE. Even "Junit" is not good enough.

"Unit testing" is a buzzword. You write something and then you write what you expect in the unit test. For example, you write a function call add3, you supply inputs in your unit test, and you supply the expected output, like providing 1,2,4 and expect 4,6,7. Tedious AND boring additional work. What good is it if you write your own test? Better: somebody else writes your test case. Yes, the idea of unit test is to re-run everything, preferably automatically, so you make sure new code does not break old code. Some people go overboard, "test driven programming", in which you write tests first. Now that's a bit too much obsession with unit testing.

I've got some reviewing to do before going to my next buzzwords interview. Some of the newest buzz things are Ruby, Spring Framework, Hibernate and all that.

What employers should look for: problem solving skills and coding ethics. Great developers pick up things quickly, whatever it is. Coding ethics are writing maintainable, followable, efficient, documented code. One usually does not need elaborate OO designs such as aggregation vs composition. Rather, you need a MINIMAL model to describe what you really need, rather than over-engineering to get impossible-to-maintain spaghetti classes with all those unfollowable "factories" and stuff. Often true in programming (AND in life): simple is beautiful.