in reply to Re^2: The Accessor Heresy
in thread The Accessor Heresy

I would be interested to see what you consider to be a maintenance nightmare about the interface.

There's nothing all that onerous about the interface but the interface isn't what gets maintained; the implementation is.

In one fell swoop—and with an extremely simplistic example no less—you've almost doubled your number of methods and tripled your number of classes. Your number of lines of code has probably grown in proportion to those numbers... somewhere between one and two hundred percent. With that comes more chance for errors and a bigger haystack to find them in. On top of that, you've given yourself the choice of keeping those classes and methods in separate files or living with multiple methods with the same name (get, set, new) all in one file. All at the expense of performance and for what purpose again?

-sauoq
"My two cents aren't worth a dime.";

Replies are listed 'Best First'.
Re^4: The Accessor Heresy
by Roy Johnson (Monsignor) on Nov 28, 2005 at 19:02 UTC
    The interface is the important thing. The interface is a big part of maintenance, because (presumably) the interface will be used in lots of code.

    Your measurement of code complexity is deceiving. For each property, the only additional code is the new method, which is trivial. With more methods on an object, the overhead as a percent would shrink. The whole idea behind OO design is that it is intended for scalability, not that it can implement trivial things trivially.

    All at the expense of performance and for what purpose again?
    Expandability, for one. If you haven't anticipated all the functions that will be handy for your properties, you're stuck implementing them as additional operate_on_Doohickey type procedures unless you change all the Doohickey-related methods. Your Doohickey can never be a real boy object. I can just add the methods to the Doohickey package, and away they go. And if I have to debug it, my haystack is actually smaller, because it's modular.

    I'm not saying it's always the way to go — I'm sure it's often not — but it is something to consider. You seem to be saying that it's never the way to go.

    Caution: Contents may have been coded under pressure.
[reply]
[d/l]
[select]
      I'm not saying it's always the way to go — I'm sure it's often not — but it is something to consider. You seem to be saying that it's never the way to go.

      Certainly it is sometimes useful; which is why it has been around for ages and is used extensively. Think "has-a" relationships and delegation (original def'n, i.e. forwarding or consultation or wtf you want to call it.) It's the wholesale application of this design even where it makes no sense and costs a lot more than it buys that I disagree with. As in your example, for instance.

      An "Area" class? What in heaven's name for? (I haven't seen one compelling reason for one in this whole thread.)

      What I take issue with, really, is your motivation behind this which, from your OP, seems to be centered around these statements of yours:

      In OO, things that you interact with are supposed to be objects, and you interact via their methods. Accessible properties are things that you interact with, but they often aren't implemented as objects, and their methods are owned by their parent objects.
      In other words, it really seems you are saying something like, "In OO, things that you interact with are supposed to be objects and, since we interact with attributes let's make them all objects." As if that's reason enough in itself.

      I'm saying as loudly and clearly as I can that it's not reason enough. In the example you've given you've created a lot of bloat for no real gain and , worse, you've paid costs in terms of both performance and maintainability. The natural conclusion: over-engineering gone awry... It's the... uh... Death of KISS.

      But, if you want to retract most of your original node and instead say something like "sometimes it's useful to implement a has-a relationship" or "delegation (forwarding/consultation/whatever) is a nice technique to understand" then, by all means, I will agree with you.

      -sauoq
"My two cents aren't worth a dime.";
[reply]
        Think "has-a" relationships
        Every property is a "has-a" relationiship. A circle "has-an" area. An employee "has-a" salary.
        It's the wholesale application of this design even where it makes no sense and costs a lot more than it buys that I disagree with.
        Since I didn't endorse the wholesale application of that design, I have no idea why you're disagreeing with it to me.
        An "Area" class? What in heaven's name for?
        I never suggested that an Area class was, specifically, a good idea. I'm sure you've seen examples before that are not pulled from real world usage.
        In other words, it really seems you are saying something like
        Of course, I've said nothing of the kind. If you would concern yourself with what I say, rather than what it seems like I'm saying something like, we might both be significantly less annoyed.
        if you want to retract most of your original node [...] I will agree with you.
        It's not at all clear that you're familiar with the original node. I can't retract most of "what it seems like I'm saying something like." I could only retract something I said. I explained that the usual implementation of accessors is not OO design, and that's why they rankle. I demonstrated what an OO approach would be. You haven't disagreed with any of that.
        Caution: Contents may have been coded under pressure.
[reply]

In Section Meditations