[Tutor] Class access rules

Alan Gauld alan.gauld at yahoo.co.uk
Mon Mar 7 20:56:56 EST 2022


On 08/03/2022 00:33, Phil wrote:
> 
> On 7/3/22 22:42, Alan Gauld via Tutor wrote:

>> class BlinkingLed(Led):
>>     def blink(self, rate=1):
>>        # ideally put this loop in a thread
>>        if not rate: #stop any existing blinks
>>        while rate:
>>           self.toggle()
>>           sleep(rate)
> 
> This is pretty close to what I have done except my blink is a method. 

Note that blink() is a method here too, just restrictred
to the subclass.

myLed = BlinkingLed()

myLed.on()   # can still use normal Led methods
myLed.off()
myLed.blink()  # but can also blink.


> I looked up the model/view object programming idea the last time this 
> came up and I didn't understand how to handle the position of the LED 

Position is part of its visual representation so goes in the view.

But MVC is hard to get used to, and more difficult because there
are very many variations that all tackle the same basic structure
but use slightly different approaches. Ultimately they all aspire
to:

Model - controls the data and logical operation of the object

View - controls everything about how the object appears

Controller - Handles the interaction of the object and the user.
It determines whether a user action requires a model or view
method (or both)

>> The amateur approach is just do it for the GUI you are
>> actually using and worry about multi-platform as and
>> when you need it!
> 
> It feels like cheating, but that's what I've done this time.

It's not cheating but it tends not to be very scaleable or
portable so leads to ore work on a long running project.
But most amateur projects are not that long lived or
required to be that portable or scaleable.

-- 
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




More information about the Tutor mailing list