Beefy Boxes and Bandwidth Generously Provided by pair Networks
Your skill will accomplish
what the force of many cannot
 
PerlMonks  

Re^3: The Accessor Heresy

by gjb (Vicar)
on Nov 28, 2005 at 17:12 UTC ( #512287=note: print w/ replies, xml ) Need Help??


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

The point I'm trying to make is that certain properties are derived from others, and while you can go in both directions, there's often a good point not to do so. I agree that there are without any doubt some circumstances in which you'd determine the radius from the area, but this is irrelevant to the discussion.

My point is that getters and setters very often don't come in pairs.

I hope this clarifies things a bit, -gjb-


Comment on Re^3: The Accessor Heresy
Re^4: The Accessor Heresy
by sauoq (Abbot) on Nov 28, 2005 at 17:40 UTC
    My point is that getters and setters very often don't come in pairs.

    Okay, you have clarified your point successfully. I don't really agree with this either, though. It all depends on what you have to do with your objects. Having two or more inter-related properties, any of which can be set and thereby affect the others, is not particularly rare.

    Running with the original example, if you sold custom made hand-woven circular rugs and charged by the square foot, you might be able to imagine situations in which setting either the area or the radius might be important.

    -sauoq
    "My two cents aren't worth a dime.";
    
Re^4: The Accessor Heresy
by Roy Johnson (Monsignor) on Nov 28, 2005 at 18:36 UTC
    getters and setters very often don't come in pairs
    To help in applying what you've read here to situations that aren't specifically covered, think about whether something is conceptually a property. If you've got a bunch of operate_on_Doohickey type methods, regardless of whether any of them happen to be get_ or set_, you probably have in your model the concept of a Doohickey property.

    If you've got only one operate_on_Doohickey method, there's still probably a Doohickey object in your model, but it's not interesting enough to implement as an object. Of course, you might expand your functionality in the future, in which case you might end up wishing you had coded it up as an object.

    I definitely wouldn't code up an object for a read-only property. If Area wasn't settable, then my Circle object might have an Area method that simply returned the area of the Circle. Note that it wouldn't be getArea. But if it had numerous possible output formats, I'd have it create a Measurement object (not a sub-object, but one that exists outside of the Circle class hierarchy, because it's not specific to the domain of Circles) so I could get Area->inSqFeet or whatever.

    The design decisions are yours, of course.


    Caution: Contents may have been coded under pressure.

      Hm, I'm a bit suspicious about the manipulating the "inner" Doohickey object, but it's hard to tell without the specifics. If it were my code I'd start analyzing dependencies and refactoring, but then again, it's hard to tell without code.

      To me, it smells of an object model which is not quite aligned with what it is trying to model.

      As ever, just my 2 cents, -gjb-

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://512287]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others browsing the Monastery: (11)
As of 2014-09-18 07:49 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    How do you remember the number of days in each month?











    Results (109 votes), past polls