On 12/02/13 01:34, Steven D'Aprano wrote:
If the class keeps a list of all instances, then the class method
could walk the list and operate on each instance in turn. (But why
would you do that?)
Because its how classes work in some languages (like smalltalk).
The class object represents all instances of the class.
Although class methods could do anything, it is hard to think of
actually useful things for them to do apart from being used as a
constructor.
Again its the norm in Smalltalk apps to implement electors(searches) and
other class wide operations in the class methods. Most Smalltalk classes
have at least 5 or 6 class methods.
Which is to say a subset of the class Book.
Therefore quite reasonably a class method.
Just a minute, I think that is completely wrong. A Book is not a set,
so how can you have subset of it?
A Book is an instance of the class Book.
Book is a class of object encompassing all books.
So returning a subset of all instances of the class is normal class
method behaviour.
What is a subset of "Pride and Prejudice"? Perhaps chapter 5.
That might be a chapter or two? But Pride and Prejudice is not the class
Book, it's an instance of Book.
There are more problems with this idea that you query the Book to get
a list of books by some author. Suppose you did this:
prpr = Book("Pride and Prejudice", "Jane Austin")
prpr.list_by_author()
No, you don't query the instance, you should query the class.
Book.list_by_author() # -> a dict of lists keyed by author name?
(One of the unfortunate features of Python's implementation of
class methods is that you can call them from an instance which
doesn't really make sense! IMHO)
Now *each and every* book is responsible for tracking all the other
books by the same author. This is a lousy design. Even worse:
prpr.list_by_author("Jane Austin")
since now books are responsible for tracking ALL books by ALL authors,
Which is why it should be a class method not an instance one.
And in the real world we'd do that by building class methods
querying a database.
Of course, books should know their own author, not the authors of other
books, but authors should know all their own books:
instances should, I agree.
The Book class should know about all books in the class.
First off, by convention the first argument to a class method should be
called "cls", not "self".
Yes, my bad.
Although it is of course only a Python convention.
Secondly, here you are relying on a mysterious global "config", which
points to a bookfile. What does this have to do with a book?
The storage mechanism is an implementation detail. In Smalltalk its part
of the infrastructure of the runtime.
- Does a nail keep track of the packet it came from?
No, but the nail factory may keep track of the nails it
produces, or at least the batches...
- Why should a book keep track of the catalog it was listed in?
A book wouldn't. but the Book class might.
The rest of the method's design is also poor. You have already read
the file once, to get the initial set of books. So why read the file
again, every time you want to get some piece of information.
This I agree with. It would be better to persist the data somewhere for
a small dataset.
--
Alan G
Author of the Learn to Program web site
http://www.alan-g.me.uk/
_______________________________________________
Tutor maillist - Tutor@python.org
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor
