Re: The Accessor Heresy

Here's the question you have to ask yourself - how often do you expect to be changing the values of an attribute? Personally, when I create a circle, I don't expect to be changing its radius. I definitely don't expect to set its area. I already created the damn thing - why should I have to tell it how big it is?? It has eyes and a brain - it should tell me! Maybe something like this would be more to your liking:

package Circle;

my $PI = 3.1415926;

sub new {
    my $class = shift;
    my ($radius) = @_;

    return bless {
        radius => $radius
    }, $class;
}

sub radius {
    my $self = shift;
    return $self->{radius};
}

sub area {
    my $self = shift;
    return $PI * $self->radius ** 2;
}

sub stretch {
    my $self = shift;
    my ($amount) = @_;

    $self->{radius} += $amount;

    return;
}
[download]

You'll note the stretch() subroutine - that allows you to alter the size of the circle. But, instead of re-setting the radius, you're $cicle->strech( 3 )'ing, which makes more sense from a reader's point of view.

Most accessors in Perl are there for the object itself, not for the client. In Ruby, for instance, I would write that Circle class as so:

class Circle
    attr_reader :radius

    @@PI = 3.1415926
    @@PI.freeze

    def initialize ( r = 5 )
        @radius = r
    end

    def area
        @@PI * @radius * @radius
    end

    def stretch ( amount = 1 )
        @radius += amount
    end
end
[download]

@x is an instance attribute and @@X is a class attribute. freeze() marks it as a constant. The ( x = 1 ) in the method declarations are default values.

My criteria for good software:

Does it work?
Can someone else come in, make a change, and be reasonably certain no bugs were introduced?

Comment on Re: The Accessor Heresy Select or Download Code

Replies are listed 'Best First'.
Re^2: The Accessor Heresy by QM (Parson) on Nov 28, 2005 at 17:04 UTC
I already created the damn thing - why should I have to tell it how big it is?? (My comment here may be too specific for the general question. If I'm off base, someone poke me gently.) Suppose you have a circle, and now its area needs to be changed. Do you compute the corresponding radius, or do you just set the area, and let the circle compute the radius? Suppose it's not Euclidean geometry, but spherical. The circle object should already be instantiated with the geometry parameters (degree of space curvature). You can set the area, and the radius and circumference are updated for you. (Note that in spherical geometry, you can have a radius and circumference of zero and still have a positive area.) I guess it depends on what the object's capabilities are, and whether you want to derive the settable attribute yourself (radius based on area), or have the object tell you. -QM -- Quantum Mechanics: The dreams stuff is made of	[reply]
Re^3: The Accessor Heresy by dragonchild (Archbishop) on Nov 28, 2005 at 18:52 UTC
Suppose you have a circle, and now its area needs to be changed. That's a requirement that would mean a new feature. Something like: `# Perl: sub set_area_to { my $self = shift; my ($area) = @_; $self->{radius} = sqrt( $area / $PI ); return; } # Ruby def area= (new_area) @radius = Math.sqrt( new_area / @@PI ) end # Note, this means that the Ruby version allows for: # circle.area = 22 # And it will DWIM` [download] I fail to see the problem. My criteria for good software: Does it work? Can someone else come in, make a change, and be reasonably certain no bugs were introduced?	[reply] [d/l]
Re^2: The Accessor Heresy by Roy Johnson (Monsignor) on Nov 28, 2005 at 17:00 UTC
Considering that this class exists in a vacuum, I don't think it's valid to comment on what functionality might be useful. Is it so inconceivable that someone might want a circle that covers a specified amount of area that the notion eclipsed the topic of the meditation? Caution: Contents may have been coded under pressure.	[reply]
Re^3: The Accessor Heresy by dragonchild (Archbishop) on Nov 28, 2005 at 18:55 UTC
I didn't explain myself well enough. The point is that accessors are poor design - they are telling you that you haven't sufficiently thought through the interface. Let's put it another way: If you expose your attributes through the use of accessors, you have coupled your client to your implementation. Yes, you can have fake accessors like your Area accessor, and that can be a powerful tool. But, I think it's a poor way to have people think about your object. I strongly urge you to take a look at Ruby's Array, Hash, String, and File classes. That is the standard I am now holding myself to when it comes to class design. My criteria for good software: Does it work? Can someone else come in, make a change, and be reasonably certain no bugs were introduced?	[reply]
Re^4: The Accessor Heresy by Roy Johnson (Monsignor) on Nov 28, 2005 at 19:34 UTC
They are not "fake accessors", they are object-oriented accessors, as opposed to the usual method-oriented accessors (neither of which couples the interface to the implementation). Properties of an object are a legitimate part of the object model, not merely part of its implementation. They are conceptual objects. Method-oriented design (where the object name is embedded in the name of a parent object's method, or is passed to it) sweeps that under the rug. There is reason to do that; I'm not saying it shouldn't be done. I just think people should be aware of why it's done. Because it rankles. Accessors certainly can indicate poor design, but they don't always. Some objects are intended to be freely manipulated. The objects in a drawing program, for example. Or the accounting books at Enron. The object has to model the process, it can't dictate it. Caution: Contents may have been coded under pressure.	[reply]
Re^2: The Accessor Heresy by sauoq (Abbot) on Nov 28, 2005 at 17:12 UTC
I'm with Roy Johnson and QM here. You, like gjb, just seem to have a preconceived notion of what a circle object should do and be. -sauoq "My two cents aren't worth a dime.";	[reply]
Re^3: The Accessor Heresy by dragonchild (Archbishop) on Nov 28, 2005 at 18:49 UTC
No, I have an initial implementation of a circle object with an example of how that implementation can be extended without ever giving outsiders access to the attributes. My criteria for good software: Does it work? Can someone else come in, make a change, and be reasonably certain no bugs were introduced?	[reply]
Re^4: The Accessor Heresy by itub (Priest) on Nov 28, 2005 at 20:51 UTC
Which attributes? What are the "attributes" and why should the user care? The only thing the user of an object should care about is being able to do whatever he needs with the object, which may include getting and setting certain "observable" properties, while the methods take care of keeping the object in a consistent internal state. The actual attribute stored internally by a circle object might turn out to be the perimeter, but that doesn't affect the circle's user at all, as long as he is able to get the radius, or whatever he needs, out of the object. If the user then wants to set or get the perimeter and the implementation turns out to be a trivial "accessor" because it happens to match the internal structure of the object, it doesn't make any difference and is not bad design.	[reply]