[Tutor] Class access rules

[Alan Gauld]

On 08/03/2022 01:08, Phil wrote:

>> Actually I'd advocate having on/off (and maybe toggle) methods.
> 
> That's how this thread started, I was wondering if I should have methods 
> to set the LED's state rather than setting the state attribute directly. 

but there is a world of difference between having methods to set the
"state" on/off and having metjods to turn the LED on/off.
The code may look the same but to the user the latter is much more intuitive

myLed = Led()
myLed.setState(True)

myLed = Led()
myLed.on()

The second is much more easy to understand and gives no clue
to what the internal data structures look like.

> This is how I use the state attribute in my toggle method:
> 
>      def toggle(self):
>          self.state = not self.state

Which s fine. The user doesn't need to know how you do it.

> I also use the LED's state to determine the LED draw fill colour.

Yes, and that would be true whether you controlled the visuals
in a View or directly in the Model.

> Perhaps I should change the name state to is_on? It would still be a 
> boolean flag.

That would remove the need for the predicate method but
you should still have on/off operations(ie methods).

Think how clumsy this looks:

myLed = Led()
myLed.is_on = True

compared to

myLed.on()

The direct command is how you use a LED. You throw a switch
and it turns on, you don;t  worry about its internal state.

> That's what I was originally asking, no doubt clumsily, "Should I modify 
> the class by adding setter and getter methods instead of directly 
> accessing the instance attributes?"

seytter/getters impy modifying an intenal attribute.

on/off/toggle are operations on a real LED.
The internal code is identical to set/get methods but the
difference in name makes a huge difference to how your users
(which might just be you!) perceive the use of the LED object.

> on, off, toggle, set_size, set on_colour and set_off colour. I cannot, 
> at the moment, see a need for any getter methods. Currently all of this, 
> except for toggle, are achieved through direct access to the attributes.

They shouldn't be. They should be actual methods even if
those methods do just change the internal state attribute.

The need for an is_on() method (or renamed state attribute)
would be especially useful if you separate the model and view.
The view needs to query whether the LED is on to know what
colour to display. (Even if the colours are supplied by
the LED too!)

> On and off methods would negate the need for a set state (or is_on) 
> method or to set the state attribute directly, because the on, off and 
> toggle methods would set or reset this flag.

Correct. That's what I mean about the internal state only
being there to support the exposed operations.

> The class constructor's current default arguments are, state=False, 
> size=10, on_colour='red', off_colour='black'.

If you replace state with is_on I think tat looks reasonable.

Then create a LedView class that takes things like position,
size, shape, model as init arguments. Every time the LedView draws
itself it will look up the current LED status via the is_on
attribute and use the on/off color attributes to draw the Led.
but the control of its position and size within the GUI are
entirely the View's own responsibility, the Led doesn't
need to know anything about that.

-- 
Alan G
Author of the Learn to Program web site
http://www.alan-g.me.uk/
http://www.amazon.com/author/alan_gauld
Follow my photo-blog on Flickr at:
http://www.flickr.com/photos/alangauldphotos