in reply to The Accessor Heresy

I think you've just started to create some useless abstractions. Even in a pure OO language, this wouldn't make much sense at all; instead, Area and Radius properties would be some sort of number objects. In Ruby, for instance, they'd probably be Floats.

The only advantage is a better-organized object.

Sorry, but I don't see any better organization here at all. In fact, it seems quite a bit messier to me. You've broken the KISS principle entirely. I understand you are just musing here... but I highly suggest you don't write any actual code like this. Your maintainers will hate you for it.

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

Replies are listed 'Best First'.
Re^2: The Accessor Heresy
by Roy Johnson (Monsignor) on Nov 28, 2005 at 17:19 UTC
    Area and Radius properties would be some sort of number objects
    Well, they are. I mentioned that you could tie them, if you want to be able to manipulate them more like native numbers. But it's just about as easy to get the value, manipulate it, and put it back. This is exactly the same thing you'd do with parent-level getters and setters.

    I don't see any better organization here at all. In fact, it seems quite a bit messier to me
    In my view, having getFoo, setFoo, doSpecialThingWithFoo, etc. is analogous to having $var1, $var2, $var3 instead of @var. Having like things grouped together under one heading is the improved organization I'm talking about.

    I would be interested to see what you consider to be a maintenance nightmare about the interface. If your beef is with the implementation, well, that's always subject to refactoring.

    Caution: Contents may have been coded under pressure.
[reply]
[d/l]
[select]
      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.";
[reply]
        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]

In Section Meditations