[Tutor] Object oriented design

[Alan Gauld]

On 22/12/15 00:14, jamie hu wrote:

>    Thanks Alan. I was thinking about making a list of objects and search
>    through it, but wasn't sure if that was right way.

For small numbers of objects( aa few hundreds say) its the easiest option.

>    I wasn't sure instantiation needed when using database, 

It makes life easier but only instantiate the objects you
need to work with.

If doing bulk updates or just searching for specific data
you can write SQL functions that work at database level.
But remember the rule of OOD - objects do it to themselves.
So you need to instantiate the objects to be able to
call their methods.

Sometimes a hybrid approach can work. Store the objects
in a dict keyed by ID. Use SQL to identify the object
you need then use the ID to fetch it from the dictionary
if its already instantiated otherwise use an ID based
init() method to fetch it from the database. That way
the select only has to return an ID and the object
instantiation fetches the specific data when you
need it. Remember that any updates to instance data
need to be written back to the database... The idea
is usually to  minimise the time any object lives in
memory since that's when its most vulnerable to unrecorded
changes and especially if more than one client or app
is accessing the same data.

>    that's the way. So ORM libraries do this work (fetch data and return
>    instantiated objects) behind the scenes??

Yes, that's exactly why they are used. They hide the fact
that there is a database there at all, it looks like you
are just working with objects in memory. At least that's
the theory, in practice there are usually some compromises!

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