N. Alex Rupp's Blog

Programming Archives

Mark Proctor added Drools DRL schema to CVS today!

For more information on DRL schema, visit the Drools Project Site

Please pass the StringBeans -- IoC-3 Components and String Dependencies

It boils down to this:

You can use Picocontainer's constructor-dependency-injector strategy to automatically pipe an object instance into an action component, with the understanding that once the action is executed, it will alter the state of its dependency objects. This is one of the core principles of the WARS style. So, you create an object, invoke the execute() method on it, and assume that the dependency object has been altered. This strategy makes good sense and works very well in most cases.

But what if the component's dependency is a String object?

I'm not positive, but I'd bet that this is a fairly common problem and with the rise of constructor-dependency-injector strategies will become more common. Assume for a moment that you can only pipe your string into a component by way of its constructor, and that its execute() method has a void return value. Of course, you could easily write a simple object that takes a String parameter and returns another String parameter, but it's a different object. But in my case, that is neither possible nor desirable.

I want to be able to pass a String into an object, tell that object to operate on it, and have my version of the String change in turn. I can do this with any other object, just not a String. Has this problem arisen in any of the various finite-state machines or other state-processing engines?

The obvious solution to this problem, then, is to wrap up the String in a simple component (I'm calling it StringBean). You can pass the wrapper object to the constructor (or method, in my simple example below).

I'm fine doing this, but I don't want to create a stupid dependency if I can help it. Can anyone suggest a different / better way to overcome this problem (excluding the unacceptable solutions listed above)? It's a tricky problem, because strings are "separate but equal" with other objects in Java.

(Here's a simple class with a main method to illustrate my point.)

public class StringTester {

    public static void main(String[] args) {
        String s = "Hello, World";
        System.out.println("Starting state: " + s);
        funk(s);
        System.out.println("Trial 1 -- ending state: " + s);
        System.out.println("--");

        StringBean b = new StringBean(s);
        soul(b);
        System.out.println("Trial 2 -- ending state: " + b);
    }

    // does not alter the state of the incoming object
    private static void funk(String s) {
        s = s.toUpperCase();
        System.out.println("in funk: " + s);
    }

    // alters the state of the incoming object
    private static void soul(StringBean b) {
        String s = b.toString();
        b.setString(s.toUpperCase());
    }

    private static class StringBean {
        private String s;
        private StringBean(String s) {
            this.s = s;
        }

        public String toString() {
            return this.s;
        }

        private void setString(String s) {
            this.s = s;
        }
    }
}

Writing software is like driving a bus.

The best software engineers I know make writing code the central part of their day. Like playing a sport or a musical instrument, writing software requires first that you show up.

While the three of us were having coffee, a friend of mine once asked Dain Sundstrom how long it would take to become a really good Java developer. Dain's answer was "six hours . . . every single day."

You'd be amazed how many talented writers I know who don't succeed at writing (software or otherwise) simply because they don't sit down and write. Ultimately, the results are never as good as you want them to be, and what you want is never as good as people need it to be. So you've got to fall in love with the process as well as the product. You might not get paid for it. But if you love the process you'll get something to sustain you while you learn. You're not guaranteed to get better if you sit and write. But you're guaranteed not to get better if you don't.

Also, don't get too attached to your work. You might be proud of it, but don't get so proud that you resist hacking it to pieces in order to improve it. This was a hard lesson for me early on. But now, I've learned to sustain myself creatively by rendering all of my work from the day before worthless, or at least trying to. It means I'm doing my job. I call this practice "eating your babies". Some corporations take this mentality to an extreme and hire a division whose sole purpose is to dream up ways to put the parent company out of business before the competitors do. Then they incorporate the findings into their business strategy.

Baby eating requires you to simultaneously be more critical and more forgiving of your work.

My two cents on becoming a better programmer: long hours and good-old Jonathan Swift style baby eating.

I finally get IoC-3

It doesn't make sense to clutter the action API with accessor methods for these values in a class meant to abstract actions from the framework, so I just have a generic accessor for the mdbean. Then the classes that need it can just pull the values directly out of the MDBean.

If there was a way to synch the internal values with the IDE, I'd be set.

What I couldn't figure out before was how IoC-3 or "dependency injection" worked with subclasses. But you just have the subclass make a call to the superclass constructor (just like in Matt Albrecht's IFTC test package), which is so simple I had to laugh at myself for not using it earlier. I use interfaces so much that I don't know all the subclassing tricks yet. Every now and then something sneaks up on you that you realize you should have known earlier. Like thread local. And state coupling.

This work is licensed under a Creative Commons License.