< == Assorted ==

< == Forgotten factory ==
< A colleague showed me the following piece of non-working code:
< Handler h = new Handler();
< if (h == null) {
< // code that handles an error, abbreviated for clarity
< }
< Apparently, the previous version used a factory to produce the Handler! However, now that it uses a constructor, the if statement will never be true -- which was probably not what the programmer intended.
< = Inheritance =
< Inheritance is pretty worthless if the rest of the design isn't object-oriented. This may sound pretty obvious, but I've came aboard lots of projects where people used an OO language, but programming was pretty much procedural. I can quote a project manager saying, "I don't care about classes, as long as the code is modular." I tried to tell him that the ''unit of modularization'' would obviously be a ''class''. But being an old-school C hacker, he wouldn't listen.
< You don't use it often while modelling. Why not? Because you get to code stuff while on an existing project. So, there's a whole bunch of persistent objects and you are asked to bolt on some new functionality. The functionality is hard to model in object oriented terms, it's basically a series of steps that have to be taken to transform outside messages into data. (Whether that outside message is user input or stuff coming in on a socket, doesn't really matter now).
< So you try to find an object in there. But there isn't! Yeah, a couple of methods which need a common variable or two. But not one of those really cool, really nice objects that they've got modelled in your UML book.
< This brings some complications. If it's just a bunch of steps, then you can probably only think of one method that's called, say, process(). This method will be put in a class and it'll use a bunch of private methods, because otherwise process() will grow too big.
< Later, you have another type of the same message. It's the same, only has an extra attribute because the version of the protocol was incremented. So you think, great, inheritance. I'll just inherit the object I created and then change this one method. *bzzzzzzt* wake up. You just created a class with almost all methods private. You can't inherit those. So you say, no problem, I'll make them protected. *bzzzzzzt* wrong again. Read up on your inheritance. They'll never be called, inheritance doesn't work like that. Example:
< public class JournalMessageProcessor {
<
< public JournalMessageProcessor() {
< }
< public void processMessage(JournalMessage message) {
< doComplicatedStuffStepOne();
< doComplicatedStuffStepTwo();
< doComplicatedStuffStepThree();
< doComplicatedStuffStepFour();
< }
< private method doComplicatedStuffStepOne() {
< /* do something */
< }
< private method doComplicatedStuffStepTwo() {
< /* do something */
< }
< private method doComplicatedStuffStepThree() {
< /* do something */
< }
< private method doComplicatedStuffStepFour() {
< /* do something */
< }
< }
< So, you are told that a new addition to the protocol was devised and now you have a version of the JournalMessage
< Shit I'm getting the mixed up. This needs some work.