It can also be convenient to maintain several different lists of objects based upon their type, so for example, one list of all the ducks, one of all the turtles, and one of all the clouds, but the reasons for this are likely beyond the scope of this question (one example: to minimize the amount of graphics state that must be changed between 'batches').
Quick code example:
Now, all of the drawing is called from a single place in your application.
EDIT: One benefit to using this approach is that Draw calls aren't scattered about. Another (more important) benefit is that each class handles the drawing of its instances. So your main application doesn't need to know (or care) how a ball is drawn - all it knows is that (because of the Drawable interface) a ball CAN be drawn (by calling ballObject.Draw(g)). Instead, the Ball class is the only file that holds the code which specifically describes how a ball is drawn. So if you want to change this later on, you only have to modify that one function in the Ball class, nowhere else.
It can also be convenient to maintain several different lists of objects based upon their type, so for example, one list of all the ducks, one of all the turtles, and one of all the clouds, but the reasons for this are likely beyond the scope of this question (one example: to minimize the amount of graphics state that must be changed between 'batches'). This approach is a little more flexible later on down the road.
Wheather you maintain one unified list of Drawables, or multiple lists of objects, you absolutely should define a "Draw" function in the specific class, for the above-mentioned reasons. It might seem like it's adding more code right now while the drawing routines are simple, but once you start having drawing lines that consume pages and pages of code, you'll be very glad that that code is sequestered away in a specific place, not littered about your main game loop with everything else.