2

I am trying to understand if there are best practices around than the one below. So in our project we had created an interface IForm like below:

class IForm {
 protected:
  IForm() {}

 public:

  virtual ~IForm() {}
  virtual const std::string& GetId() const = 0;
  virtual const std::string& GetTitle() const = 0;
  virtual void SetTitle(const std::string& title) = 0;
  virtual void SetFormError(const std::string& error_text) = 0;
  virtual void ClearFormError() = 0;
};

And then the requirement came to have more functions and therefore we created new interface IForm2:

class IForm2: public IForm {
 protected:
  IForm2() = default;

 public:
  virtual ~IForm2() = default;
  virtual void RemoveWidget(const std::string &id) = 0;
  virtual void Clear() = 0;
};

My question is:

Is there a way around this ? Instead of adding new interface, is there some design pattern that I can use to implement newer requirements rather than adding newer interfaces?

I know the above method works fine. I am just looking for alternatives to implement functionalities.

Monku
  • 2,440
  • 4
  • 33
  • 57
  • You could just modify the existing interface. – Jesper Juhl Mar 15 '17 at 21:10
  • Why are you trying to simulate C# design in C++? I very much doubt you'll end up with an efficient design. – DeiDei Mar 15 '17 at 21:12
  • @DeiDei its not C# per say. its one way of programming interfaces. What I am looking for is a better way. – Monku Mar 15 '17 at 21:13
  • Btw; this " virtual ~IForm2() = default;" adds nothing useful over what you already got from the base class. – Jesper Juhl Mar 15 '17 at 21:13
  • @JesperJuhl I could but the architect argues that the interfaces are published to other teams so should remain unchanged. And any new functionality must be added in newer interface deriving the old one. – Monku Mar 15 '17 at 21:15
  • @JesperJuhl I agree. If we can ignore that :) – Monku Mar 15 '17 at 21:15
  • Perhaps "inline namespace"s are what you are looking for?? Maybe read this: http://www.gotw.ca/publications/mill21.htm – Jesper Juhl Mar 15 '17 at 21:21
  • 3
    @Monku If the code is all internal to your organisation, go hit your architect with a clue-by-four and get the other teams to adjust to the new interface ;-) no point keeping legacy crap around or creating technical debt unless it's to please a customer (who's hopefully paying for it). When it's all internal, the code should just be fixed/updated IMHO and then ppl just have to deal with it.. – Jesper Juhl Mar 15 '17 at 21:39
  • Why would you need an alternative? It's difficult to answer without knowing what properties should new alternative have. – PcAF Mar 16 '17 at 07:07

1 Answers1

0

I've never actually had need of it but you might want to look up the decorator design pattern.

Here's a link to a SO answer about decorators.

Decorator pattern in C++

Community
  • 1
  • 1
soulsabr
  • 895
  • 4
  • 16
  • if I understand it correctly, decorator pattern does not add functionalities, it makes existing dynamic. – Monku Mar 15 '17 at 23:41
  • "In object-oriented programming, the decorator pattern (also known as Wrapper, an alternative naming shared with the Adapter pattern) is a design pattern that allows behavior to be added to an individual object, either statically or dynamically, without affecting the behavior of other objects from the same class." -Wikipedia So, per the definition, you can add additional functionality. But, as per the discussion under the question, is this the right thing to do? Probably not since the upkeep will eventually become over bearing for very little gain. – soulsabr Mar 16 '17 at 13:20