Re: accessor/mutator functions

From: Dan Sommers (me_at_privacy.net)
Date: 03/01/05 

Date: 28 Feb 2005 18:49:39 -0500

On Mon, 28 Feb 2005 23:08:04 GMT,
Andrew Dalke <dalke@dalkescientific.com> wrote:

> On Mon, 28 Feb 2005 15:50:22 -0500, Dan Sommers wrote:
>> The reason their code is so inflexible is that they've filled their
>> classes with boiler plate get/set methods.
>>
>> Why do users of classes need such access anyway? If my class performs
>> useful functions and returns useful results, no user of my class should
>> care about its attributes. If I "have to" allow access to my attributes
>> in order that my users be happy, then I did something else wrong when I
>> designed the class and its public interface in the first place.

> Consider an interface to a temperature controller. It will
> have several properties:

> - current temperature (read only)
> - target temperature (read/write)
> - various tuning parameters that affect the rate of change,
> stability, etc.; eg, lookup details on a PID controller

> These are properties of the temperature controller object.
> In Python these properties are traditionally mapped to attributes.
> Under languages that don't have a __getattr__/"property" mechanism
> for separating interface from implementation these are implemented
> via get/set accessor methods.

> It is very often useful to change the temperature setting of
> a controller over time. Eg, a chemical protocol might say
> "warm from 50 to 80 over a period of 30 minutes, 1 degree
> per minute".

> In Python that might be written as:

> temp_controller = TemperatureController("/dev/com3")
> temp_controller.target = 50
> print "Bringing reactor to", temp_controller.target
> while 1:
> print "Current temperature is", temp_controller.current
> if abs(temp_controller.current - temp_controller.target) < 0.1:
> break
> time.sleep(30)

> raw_input("Insert sample and press the <enter> key: ")

> for temp in range(51, 81):
> print "Raising reactor temperature to", temp
> temp_controller.target = temp
> time.sleep(60)
> if abs(temp_controller.current - temp) > 0.1:
> print "Variance too high!", temp_controller.current

> print "DONE!"

> What's wrong with the use of attributes in this case and how
> would you write your interface?

I think I'd add a change_temperature_to method that accepts the target
temperature and some sort of timing information, depending on how the
rest of the program and/or thread is structured. It might turn into two
or three methods, depending on whether I can afford to block while
waiting, or what kind of intermediate feedback and/or error handling I
want (or one method with some carefully chosen default arguments). I
don't know how that device driver works, but it might look something
like this:

    def change_temperature_to( self, target, seconds_between_checks ):
        print 'target temperature:', target
        tell_the_device_to_change( )
        while 1:
            current = read_the_temperature_from_the_device( )
            print 'current temperature:', current
            if abs( current - target ) < 0.1:
                break
            time.sleep( seconds_between_checks )

Obviously, that code is untested! ;-)

In the case of simply reading the current temperature, and not knowing
what's inside that device driver, I'd still lean away from exposing a
current temperature attribute directly. I think part of my thinking
comes from my old Pascal days, when it made me cringe to think that
"x:=b;" might actually execute a subroutine rather than just copy some
memory around.

I'm not saying that my applications *never* access my objects'
attributes directly, just that it's one of those things that raises at
least a yellow flag in my mind.

Regards,
Dan 

-- 
Dan Sommers
<http://www.tombstonezero.net/dan/>
μ₀ × ε₀ × c² = 1

Relevant Pages

  • Re: every independent portfolios are ministerial and other personal announcements are essential, but
    ... Otherwise the interface in Will's feedback might ... Aziz sinked the green jams with regard to favourable guerrilla. ... Almost no usual floors entitle Ronnie, ... For Roger the ball's mental, depending on me it's practical, whereas ...
    (sci.crypt)
  • Re: Alternative to a thread THread in MFC??
    ... To do DMA, you need to lock all the ... This can only be done in a device driver, ... interface this bad could possibly have done them. ... >Waiting for an interrupt is done in a device driver. ...
    (microsoft.public.vc.mfc)
  • Re: Alternative to a thread THread in MFC??
    ... you have a completely unsalvageable mess and both the device driver and the ... You still talk about "interrupt received", although there is no mechanism in Windows ... interface is nearly impossible, but I'm guessing what the interface is likely to be doing. ... Waiting for an interrupt is done in a device driver. ...
    (microsoft.public.vc.mfc)
  • Re: RiscPC has stopped talking to router
    ... EtherM interface statistics ... Packets transmitted: 330 ... Module 'EtherM' is a supplier titled 'EtherM device driver' ... Small mbufs in use: 1 ...
    (comp.sys.acorn.networking)
  • Re: accessor/mutator functions
    ... > temperature and some sort of timing information, ... In the case I'm hypothesizing (haven't worked with a temperature ... interface underneath. ... Bonds have a bond type and the two atoms at the ends of the bonds ...
    (comp.lang.python)
Loading