[Tutor] Class access rules

Phil phillor9 at gmail.com
Mon Mar 7 19:33:54 EST 2022


On 7/3/22 22:42, Alan Gauld via Tutor wrote:
>
> Don't add methods you don't need (search YAGNI). One of the insanely
> great things about OOP is that it allows you to easily extend classes
> to add methods if you need them later:
The thing is, what do I need? Very few of my projects are truly useful.
> 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. A 
blinking subclass might be better.

> The professional answer to this is that you should create the
> Led as a data object (a "Model") that does the logic of switching
> state/blinking or whatever and have a separate "View" object
> that does the drawing on the GUI.

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 so 
I included it's position in the class constructor. That way either 
wxpython or tkinter knew where to place the LED and use it's own draw 
method. This is unlikely to be considered good practice.


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

-- 

Regards,
Phil



More information about the Tutor mailing list