[Tutor] Python OO

[Alan Gauld]

On 28/03/15 21:39, Juan C. wrote:

> you should also be thinking about the methods. What will a series object
> do in the context of your application?


> My app doesn't do anything specific. It's just for the sake of doing
> something. Maybe, I just create a serie instance and print all the info
> about it like title, year of launch, numbers of seasons, go through each
> season and post each episode info like title, air date, summary, things
> like that.

OK, So lets say you don't print all the info about it. Say the series 
prints its own information - or at least presents it as a string that 
you can print?

Then you just say:

s = Series(ID)
print(s)

So you want a method for getting a printable sting
from series.

But how does series print itself?
By printing each of its seasons?

class Series:
    ...
    def __str__(self):
       output = ['...']  # whatever header you need
       for season in self.seasons:
          output.append(str(season))
       return '\n'.join(output)

And how does a series print? Maybe it prints some header
details about each episode?

class Season:
    ...
    def __str__(self):
       output = ['....']   # same pattern as above
       for episode in self.episodes:
           output.append(episode.get_header())
       return '.'.join(output)

So we have an operation and we see how it ripples down
through the classes and how the data attributes support
it.

What else might you want to do with these objects beside print them? 
find specific episodes in a series(search)? List plot synopses?
Search by featured actor? others?

>> Also is date really an attribute of the series? Or is it a derived
> feature based on the seasons? And maybe should be a range, or a
> tuple of values?
>
> The date thing is a little different in each case, Serie will have only the
> year, let's say "Breaking Bad" would be 2008. Season would have year +
> month. Episode would have full date, year + month + day.

But isn't that the date of the first episode in each case? So you
don't need to store it. You can find it by asking the first episode
(of the first series) for the date.


> little "Java" there. The best thing to do would be having a self.seasons
> just like every else (self.title, self.year and so on) list of 'Season'
> instances and then I call it directly.

Yes the attributes would be self.xxx where necessary.

>> Much as before. Is the year an attribute or derived from the
> episodes? Can a series be shown more than once? Does it have
> multiple dates in that case?
>
> Year is an attribute of season. Not multiple dates, it will have the year +
> month of the first episode of the season.

Exactly, its the date of the first episode, so you can get
it on demand, rather than store it. (Of course you might store
it for performance reasons but its not necessary.)

> I don't want to create a bunch of "get" methods, I read in many places that
> Python isn't Java, you don't need "getters/setters" you can pretty much
> call the 'self.var' directly.

Thats true, but better still is to put the intelligence of
how/when the attributes are accessed into the object itself.
It owns the data so it should manipulate it.

> Again, I was thinking 'Java' there, I don't need a 'get_character' method,
> I can have a list on my __init__ and call it directly, same goes for
> crew_size, I just use len() on characters.

Yes, but you could also use the API as you need it too.
But again performance may dictate otherwise. It all depends
on what you need/want from the objects.

>> Do you have to? Why not fetch the seasons and episodes on demand?
>
> Well, let's say I create a new instance, 'bb = Serie(1396)  # Breaking
> Bad', won't I need to have my 'self.seasons' list ready, because I can call
> it anytime?

If you are net connected you can call the API anytime and save storage 
space. That way it will always be up to date, no risk of new data 
sneaking in. But it all depends on your application needs. Either way is 
valid.

I'm just trying to challenge you to step back from a data centric view. 
Objects are more than data, they are also behaviour and the behaviour is 
usually more important to the design than the data.

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