Blaine Buxton: Positronic Vibrations From Alto Dorado

In my previous post, I was writing about how I was using java's reflection API to make sure that my domain objects were conforming to the constraints of the Hibernate project. So, my objects could be persistable by anybody. At one point, I needed to know if a class was abstract (because then I know I culd't instantiate it) or final (because then this cuts down on the possibilities that Hibernate can do for proxies). Here's the code that I used:

    private boolean isAbstract(Class klass) {
        return (klass.getModifiers() & Modifier.ABSTRACT) > 0;
    }
    private boolean isFinal(Class klass) {
        return (klass.getModifiers() & Modifier.FINAL) > 0;
    }

What does this have to do with encapsulaton and minimal interfaces? In the code, they are odds with one another. The minimal interface is to simply have the getModifiers() method, but I believe this breaks encapsulation. I'm basically being exposed to how modifiers are implemented in the object, Class. Should I care that modifiers are really integers? If I got rid of the getModifiers() method and replaced it with corresponding methods isAbstract(), isFinal(), and etc. Then, I would not have a minimal interface, but I would have proper encapsulation.

I'm not trying to respark the humane vs. minimal interface debate. But, I'm trying to point out that sometimes they can be at odds with one another. And when they are at odds, which one would you pick? Me? I will always pick encapsulation because objects should always hide their internal implementations.

I also brought this topic to show that by placing more value on a minimal interface. You sacrifice one of the most important attributes of object-oriented programming: encapsulation.

posted by Blaine at 12:59 PM |  0 comments |  Post a Comment