On 28/03/15 19:06, Juan C. wrote:
The script uses the Movie DB API, and I have a Series module.
So far so good, but you probably want to hide the MDB API inside
your module so that if you replace it with another one (or
add another one later) you don't change your modules API.
In this module I have 3 classes, 'Serie', 'Season' and 'Episode'. In
__main__.py I will instantiate a serie like so 'some_random_name =
Serie(123)', where 123 is the ID of the serie in the API.
Serie class: title, year, length (X seasons), serieid and a function
get_season(self, number)
That looks like a data oriented class, which may not be a bad thing but
you should also be thinking about the methods. What will a series object
do in the context of your application? How will those data attributes
help the methods do their job?
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 "function" - do you mean method? - get_season() should probably
be a private method and maybe called by __init__()? (I'm assuming
this is the thing that talks to the MDB API?
Season class: number, year, length (X episodes) and a function
get_episode(self, number)
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?
Episode class: title, number, date and two functions, get_character(self,
index) and crew_size()
This is the core data, most of the higher level stuff can be derived
from this. And it has two methods (not functions). Or are they also just
calls to the MDB DB?
Or are they methods that your users will want to use? Itsnot clear.
A good way to design classes is the CRC technique.
For each class define
C - Class name
R - responsibility - what does the class do/own?
Collaborators - Which other classes (or APIs - which could
be classes in their own right)will the class interact with?
Many projects use a literal 5x3inch paper card index for their
classes using this technique. For 3 classes thats probably overkill!
What would be the best approach using OO? Should I use class inheritance
and how?
Inheritance implies an "is-a" relationship
Is it true that a series is-a season?
Or is a season a series - now that sounds more likely...
Is an episode a season or series?
Is a season or series an episide?
- Probably not.
Are they all 3 types of BroadcastEvent - maybe.
For now I'd go with separation, if it turns out that all
the operations in season are the same as on series then
think about converting to inheritance. Remember its similarity of
operation that defines inheritance not similarity of data.
Thats what buys you polymorphism.
What would be the best way to create the whole Serie instance with
the least API calls possible?
I don't know the API so I can't answer that.
Remember that when I create a new Serie(serie_id) I create the whole thing,
every season, every episode.
Do you have to? Why not fetch the seasons and episodes on demand?
PS: If you guys know a good book/course/tutorial about Python OO feel free
to post it here.
Lots of them, and not all python specific.
I still like Grady Booch's book OOA&D even though its C++ based.
Even better is if you get the first edition from a library since
it is multi lingual, and much better for it.
--
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
_______________________________________________
Tutor maillist - [email protected]
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor
