Making a class more generic [part 2]

Collapse
This topic is closed.
X
X
 
  • Time
  • Show
Clear All
new posts
  • Simon Elliott

    Making a class more generic [part 2]

    I have a class (actually the same one described in part 1) which
    implements a state machine. The state machine is inside a pimpl, and
    looks a bit like this:

    class foo::fooImpl
    {
    public:
    foo(void);
    void StartBloggs(con st BloggsType& bloggsStuff)
    {
    bloggsStuff_ = bloggsStuff;
    state_ = 1;
    }
    void StartJimmy(cons t JimmyType& jimmyStuff)
    {
    jimmyStuff_ = jimmyStuff;
    state_ = 2;
    }
    void Exec(void)
    {
    switch (state_)
    {
    case 1:
    execBloggs();
    break;
    case 2:
    execJimmy();
    break;
    }
    }
    private:
    int state_;
    BloggsType bloggsStuff_;
    JimmyType jimmyStuff_;
    void execBloggs();
    void execJimmy();
    };

    As before, I now want to make this code a bit more generic. The problem
    I now have is that some callers may want to only use the Jimmy code, and
    others only want to use the Bloggs code. But anyone who links my class
    gets the overhead of having both Bloggs and Jimmy, whether needed or
    not. (In my example above, I could probably dynamically allocate the
    state data bloggsStuff_ and jimmyStuff_, but I'm more interested in not
    linking the execBloggs() and execJimmy() methods.)

    Is there any way of only linking the stuff the user of the class needs,
    and still keeping the pimpl in some shape or form?
    --
    Simon Elliott







  • lilburne

    #2
    Re: Making a class more generic [part 2]

    Simon Elliott wrote:[color=blue]
    >
    > Is there any way of only linking the stuff the user of the class needs,
    > and still keeping the pimpl in some shape or form?[/color]

    Seperate the execBloggs(), and execJimmy() into seperate
    classes. Have you class only see abstract bases. Clients
    supply an implementation exec object contructed with an
    appropriate object.

    BloggsAbs.h
    class BloggsExecAbs
    {
    public:
    virtual void execBloggs() = 0;
    };

    bloggs_impl.h
    class BloggsExecImpl : public BloggsAbs
    {
    public:
    virtual void execBloggs();
    };


    foo.h
    #include "BloggsAbs. h"
    #include "JimmyAbs.h "

    class foo
    {
    public:
    void StartBloggs(Blo ggsExecAbs* bloggsExec) {
    bloggsExec_ = bloggsStuff;
    state_ = 1;
    }
    void StartJimmy(Jimm yExecAbs* jimmyExec) {
    jimmyExec_ = jimmyStuff;
    state_ = 2;
    }

    void Exec(void) {
    switch (state_) {
    case 1:
    bloggsExec_->execBloggs() ;
    break;
    case 2:
    jimmyExec_->execJimmy();
    break;
    }
    }
    };

    Comment

    • Simon Elliott

      #3
      Re: Making a class more generic [part 2]

      lilburne <lilburne@godzi lla.net> writes[color=blue]
      >Seperate the execBloggs(), and execJimmy() into seperate
      >classes. Have you class only see abstract bases. Clients
      >supply an implementation exec object contructed with an
      >appropriate object.[/color]

      Thanks - an interesting idea. I could even have all the relevant local
      state data encapsulated into the implementation object.
      --
      Simon Elliott







      Comment

      Working...