[Tutor] Design Question
Alan Gauld
alan.gauld at btinternet.com
Fri Jun 1 20:23:38 CEST 2007
<dsh0105 at comcast.net> wrote
>I think I may have sent an incomplete version of this question
Indeed and I andswered it! :-)
> So I'm looking for comments/suggestions on the key pieces of the
> design: the questions and the flash card deck:
> Psudo-code of current design:
>
> class Deck():
Better, no longer derived from Question.
> """Provides managment and informational functions about
> a set of questions to be asked methods incldue:
> __init__(questions) -- takes a list of question and creates a new
> deck with these questions.
Fine
> add_question(self,question) -- Adds a question to the current deck
Fine
> remove_question(self,question) -- returns True if the question
> was removed, False otherwise
Doesn't sound like, better to use a question style name like
is_removed(question)
But I'd ask how the deck would know? Does it keep a record
of all questions it ever stored? Or should the question be
storing its own status? I'm not sure how flash cards work
so either answer could be right.
> get_question() -- Returns the next unanswered question in the deck
Fine
> get_stats() -- returns a tuple containing: number_asked,
> number_correct, number_remaining
Fine
> shuffle_deck() -- shuffles the order of the remaining
> questions.
OK, see my other reply about ordering and keepingtrack of
current position etc.
> Deck Overrived the __len__ function so that the len returned
> is the number of questions in the deck."
Good idea!
> class Question():
Better, no longer plural
> """Provides questions to be asked
> methods:
> __init__(self,question,answer) -- question string representing the
> question.
> answer can be a text string, a tupple (for multiple correct
> answers)
> or an object implementing an is_correct() method that returns a
> boolean
Fine although handling those different answers might be easier
done using inheriance with 3 different subclasses of question
and a check_answer method over-ridden in each.
> check_answer(self,answer) -- tests to see if the answer is
> correct and returns a boolean
If its a boolean the method could be called is_correct instead. think
of how the client cpdfe will read:
if q.check_answer(ans): ...
or
if q.is_correct(ans): ...
personally I prefer the second style. But it is personal.
> Mostly I'm wondering, is this over-kill? The idea is to allow for
> the deck to be used for as wide a variety of purposes as possible.
Doesn't look overkill, but I don;t know enough to be sure.
It could be done with basic python types and a couple of
functions I suspect. But if you want to add features an OOP
design may well pay off.
Can you write a really basic version without OOP?
Or maybe write the Question class first and store them in a
basic list? Then add the deck once you have the question worked out?
> Also, I want to make it easy to write code that generates decks.
I'm not sure what that means in practice? Isn't that what your init
does?
HTH,
--
Alan Gauld
Author of the Learn to Program web site
http://www.freenetpages.co.uk/hp/alan.gauld
More information about the Tutor
mailing list