bloated base class?

centigrade0_at_gmail.com
Date: 12/09/04 

Date: 8 Dec 2004 18:23:54 -0800

Hello,

In a data processing application, that can be very roughly described as
[input]->[processing]->[output], there is a single input class, let's
call it class Input. Now the app needs to be extended to process a
different kind of input. I'd like to make use of as much of the
existing code as possible. A basic refactoring comes to mind:

class AbstractInput;
class OldInput : public AbstractInput;
class NewInput : public AbstractInput;

The problem is that OldInput and NewInput encapsulate different data.
So most of the get/set methods in OldInput don't belong in NewInput,
and vice versa. The users of these classes need the old or new
interface depending on what kind of data they work with. One option is
to bloat the interface of AbstractInput, adding there the methods from
both OldInput and NewInput... this would enable polymorphism, but it
just doesn't feel right. Anyone can suggest a nicer way to tackle this?
Thanks.

Relevant Pages

  • Re: bloated base class?
    ... > call it class Input. ... > The problem is that OldInput and NewInput encapsulate different data. ... > to bloat the interface of AbstractInput, ...
    (comp.object)
  • Re: bloated base class?
    ... > In a data processing application, that can be very roughly described ... > call it class Input. ... > The problem is that OldInput and NewInput encapsulate different data. ...
    (comp.object)
  • Re: bloated base class?
    ... > call it class Input. ... > The problem is that OldInput and NewInput encapsulate different data. ... > interface depending on what kind of data they work with. ...
    (comp.object)
  • Re: bloated base class?
    ... > So most of the get/set methods in OldInput don't belong in NewInput, ... language that doesn't support polymorphism except through inheritance. ...
    (comp.object)
  • Re: bloated base class?
    ... inheritance doesn't bring together "common" things from ... OldInput or NewInput is resolved dynamically). ... looks like I'll have to do without dynamic polymorphism, ...
    (comp.object)