On Thu, 2007-12-27 at 11:51 -0500, Brett McCoy wrote: > On Dec 27, 2007 11:21 AM, Michael Sullivan <[EMAIL PROTECTED]> > wrote: > > On Thu, 2007-12-27 at 10:38 -0500, Brett McCoy wrote: > > > From a design standpoint, I don't see why the Battle class needs > to > > > have a DrawBattle object... I would decouple those and just let > the > > > Battle class handle the data for the armies, player characters, > etc > > > and let the DrawBattle read the data as needed (almost like a > > > client/server relationship). That way, you can have multiple > battle > > > objects, perhaps, but there will always be one and only one > DrawBattle > > > object that handles the screen display. > > > > How is DrawBattle supposed to "read" the data as needed if there is > no > > DrawBattle object to feed the data to it through? > > Through public accessor methods of the Battle class. > > -- Brett > ---------------------------------------------------------- > "In the rhythm of music a secret is hidden; > If I were to divulge it, it would overturn the world." > -- Jelaleddin Rumi
So you're saying that DrawBattle should have a Battle object?
