How to go ahead with methods that only one derived class implements from a common interface?

Question

I have one interface (let's say in C++) that has been implemented by some derived classes. Let's suppose that the interface is like this:

class IBase
{
  virtual bool method_1() = 0;
  virtual long method_2(const std::string str) = 0;
  // other methods
  virtual long method_10(int value) = 0;
};

and up to now 6 different derived classes (will be more in future) have implemented the interface. In lots of algorithms in my code, I have used this interface polymorphically. e.g:

// some usage
obj = getObject();
if (obj->method_1())
{
  return obj->method_2("Hello");
}
else
{
  return obj->method_10(12);
}

Over the time, I have found that there would be lots of methods that only one derived class implements them. So, the Q is that is it the right design to put these methods in the interface or should I put them directly in the derived classes? But note that:

• If I put them in the interface, only one derived class will implement them and for the rest of the derived classes the implementation will be empty.
• If I put them in the derived classes, my implemented algorithms will not be generic anymore and I need to check the type of the derived class during my algorithm implementation.

What is the right way to go ahead in this case?

Answer 1

How to go ahead with cases in which ONLY one derived class needs to implement a method from a common interface?

If you end up in this situation then generally you have a problem with your design and should refactor.

For example in your calling code you call multiple methods on the class and make decisions based on the results of these methods. This is probably wrong. Instead you should have the logic encapsulated in the class and interface:

interface IShoppingBasket 
{
    void AddItem(Item item); //only one method
}

class ElectronicsShoppingBasket : IShoppinBasket
{
    public void AddItem(Item item)
    {
        if(item.Type == software) //logic is in the class not the calling code
        {
            this.softwareLicences.Add(item); //private method only in this implementation
        }
        else
        {
            this.physicalGoods.Add(item); //private method only in this implementation
        }
    }
}

I'm not exposing IsSoftwareLicence() or AddPhysicalGoods() because they are a concern only of the specific implementation. Not the generic interface.

This allows me to make multiple derived classes with differing functionality, but have them all perform the same task.

For the case where specific ShoppingBasket implementations need extra information, this can often be viewed as a dependency of the shopping basket:

class ElectronicsShoppingBasket : IShoppinBasket
{
    public void ElectronicsShoppingBasket (ICustomerDetailsProvider custDet)
    {
        this.custDet = custDet
    }

    public void AddItem(Item item)
    {
       if(this.custDet.GetAddress().Country == Country.NorthKorea)
       {
            throw new Exception("embargoed country"); 
       }
       .....
    }
}

Here the constructor is not inherited or part of the interface, but we enforce the requirement that a CustomerDetailsProvider is in place where ever we have an ElectronicsShoppingBasket

Again, the calling code doesn't have to know about the customer info or have any logic

class CallingCode
{
     public CallingCode(IShoppingBasket sb) //pass me anything as long as it has AddItem
     {
         this.sb = sb;
     }

     public void AddItem(Item item)
     {
          this.sb.AddItem(item); //if you need any other details that's your problem
     }
}