Dans un sens très étroit, la réponse est "Oui": en supposant que vos classes ou interfaces de base sont conçues dans un seul but, l'héritage des deux crée une classe avec plusieurs responsabilités. Cependant, que ce soit ou non "une mauvaise chose" dépend de la nature des classes ou des interfaces dont vous héritez.
Vous pouvez partitionner vos classes et vos interfaces en deux groupes principaux - ceux qui traitent de la complexité essentielle de votre système et ceux qui traitent de sa complexité accidentelle. S'il hérite de plusieurs classes de "complexité essentielle", c'est mauvais; si vous héritez d'une classe "essentielle" et d'une ou plusieurs classes "accidentelles", c'est OK.
Par exemple, dans un système de facturation, vous pouvez avoir des classes pour représenter les factures et les cycles de facturation (elles traitent de la complexité essentielle) et des classes pour les objets persistants (elles traitent de la complexité accidentelle). Si vous héritez comme ça
class BillingCycleInvoice : public BillingCycle, public Invoice {
};
c'est mauvais: votre BillingCycleInvoice
responsabilité est mixte en ce qui concerne la complexité essentielle du système.
D'un autre côté, si vous héritez comme ça
class PersistentInvoice : public Invoice, public PersistentObject {
};
votre classe est OK: techniquement, elle dessert deux préoccupations à la fois, mais comme une seule d'entre elles est essentielle, vous pouvez radier l'héritage accidentel du "coût de faire des affaires".