[Tutor] Design Question

[Alan Gauld]

<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