[Tutor] Python OO

[Alan Gauld]

On 29/03/15 20:16, Juan C. wrote:

> Current code on core.py:
>
> from pycinema.mdb import MovieDB
> API = MovieDB('API KEY GOES HERE')
>
> class Actor:
...

> Current code on mdb.py:
> import requests
>
> class MovieDB:
> ...
> def get_actor(self, actor_id):
> response = requests.get('http://api.themoviedb.org/3/person/'...
> return {'name': response['name'], 'id': actor_id, 'biography':
> response['biography']}
>
> I think the get_actor return is a bit bad. What would be the best way to
> return the data?

As an instance of your actor class would seem reasonable.
If I ask for an actor I expect to get an actor back,
not a dictionary.

> Should I use classes inside the MovieDB class (Actor, Movie, Series) and
> inside those classes have different methods to get each data, like name,
> birthday, bio, etc separately?

No, The API should just be a wrapper around the API you are using. It 
should return the Actor, Movie, etc objects that your application uses.
The whole point of the API is just to allow you to change to (or add)
a different source if needed. (It also shields you from future
changes to the API) It should act as a translator from data source
to application object. Any new source can be wrapped in the same
way so it returns the same core objects.

> Only 1 call to the API gives all this data, example (
> http://private-anon-37abaab74-themoviedb.apiary-mock.com/3/person/678). If
> I have different methods to get each data separately, I would be calling
> this same URL many times, when the best approach would be only 1.

So inside your API separate out the single data response into its 
different objects. Call the API in the API init method. Then have 
separate methods to get the actors etc which operate on that
internal stored data. Your objective should be to hide the details
of how the interface works from the application objects.

[ Aside:
If there is a lot of data returned you might even store it temporarily 
in a local data base (SQLite file maybe?) The other methods then 
translate into SQL queries into that database. Refreshing the API then 
involves fetching the latest data and updating the database. But that's 
probably only worthwhile if you are storing many hundreds or thousands 
of records.]

> I won't need to get the ID from the API, as the user must provide the ID
> when instantiating the Actor.

Can you explain how that works? Does the user create their own
random unique values? Do you use a source of unique keys?
Or could the Actor init() maybe generate an ID for the user?

But without the API knowing the ID, how does the correct data get 
selected? Surely there must be some kind of unique key for that to happen?

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