Interface vs Classe base

Quando devo usar uma interface e quando devo usar uma class base?

Deve ser sempre uma interface se eu não quiser realmente definir uma implementação básica dos methods?

Se eu tiver uma class de cão e gato. Por que eu iria querer implementar IPet em vez de PetBase? Eu posso entender que tenho interfaces para ISheds ou IBarks (IMakesNoise?), Porque elas podem ser colocadas em uma base de pet por animal, mas eu não entendo qual usar para um Pet genérico.

    Vamos dar o seu exemplo de uma class Dog e Cat, e vamos ilustrar usando C #:

    Tanto um cachorro quanto um gato são animais, especificamente, mamíferos quadrúpedes (os animais são muito gerais). Vamos supor que você tenha uma class abstrata Mammal, para ambos:

    public abstract class Mammal 

    Essa class base provavelmente terá methods padrão, como:

    • Alimentação
    • Companheiro

    Todos os quais são comportamentos que têm mais ou menos a mesma implementação entre as duas espécies. Para definir isso, você terá:

     public class Dog : Mammal public class Cat : Mammal 

    Agora vamos supor que existam outros mamíferos, que normalmente veremos em um zoológico:

     public class Giraffe : Mammal public class Rhinoceros : Mammal public class Hippopotamus : Mammal 

    Isso ainda será válido porque no núcleo da funcionalidade Feed() e Mate() ainda serão os mesmos.

    No entanto, girafas, rinocerontes e hipopótamos não são exatamente animais dos quais você pode fazer animais de estimação. É aí que uma interface será útil:

     public interface IPettable { IList Tricks{get; set;} void Bathe(); void Train(Trick t); } 

    A implementação do contrato acima não será a mesma entre um gato e um cachorro; colocar suas implementações em uma class abstrata para herdar será uma má ideia.

    As definições do seu cão e gato devem agora parecer:

     public class Dog : Mammal, IPettable public class Cat : Mammal, IPettable 

    Teoricamente, você pode sobrescrevê-los de uma class base mais alta, mas essencialmente uma interface permite que você adicione apenas as coisas que você precisa em uma class sem a necessidade de inheritance.

    Conseqüentemente, como normalmente você pode herdar somente de uma class abstrata (na maioria das linguagens OO estaticamente tipificadas que são … exceções incluem C ++), mas capaz de implementar várias interfaces, ele permite que você construa objects estritamente conforme a necessidade .

    Bem, Josh Bloch disse em Effective Java 2d :

    Prefere interfaces sobre classs abstratas

    Alguns pontos principais:

    • As classs existentes podem ser facilmente adaptadas para implementar uma nova interface . Tudo o que você precisa fazer é adicionar os methods necessários se eles ainda não existirem e adicionar uma cláusula implements à declaração da class.

    • Interfaces são ideais para definir mixins . Falando livremente, um mixin é um tipo que uma class pode implementar além de seu “tipo primário” para declarar que ele fornece algum comportamento opcional. Por exemplo, Comparable é uma interface mixin que permite que uma class declare que suas instâncias são ordenadas em relação a outros objects mutuamente comparáveis.

    • Interfaces permitem a construção de estruturas de tipos não hierárquicos . As hierarquias de tipos são ótimas para organizar algumas coisas, mas outras não se encheckboxm perfeitamente em uma hierarquia rígida.

    • As interfaces permitem melhorias de funcionalidade seguras e poderosas através do idioma da class wrapper. Se você usa classs abstratas para definir tipos, você deixa o programador que deseja adicionar funcionalidade sem alternativa, a não ser usar inheritance.

    Além disso, você pode combinar as virtudes de interfaces e classs abstratas, fornecendo uma class de implementação esquelética abstrata para acompanhar cada interface não trivial exportada.

    Por outro lado, as interfaces são muito difíceis de evoluir. Se você adicionar um método a uma interface, ele quebrará todas as suas implementações.

    PS .: Compre o livro. É muito mais detalhado.

    O estilo moderno é definir IPet e PetBase.

    A vantagem da interface é que outro código pode usá-la sem qualquer vínculo com outro código executável. Completamente “limpo”. Também interfaces podem ser misturadas.

    Mas as classs base são úteis para implementações simples e utilitários comuns. Portanto, forneça uma class base abstrata para economizar tempo e código.

    Interfaces e classs base representam duas formas diferentes de relacionamentos.

    Herança (classs base) representa um relacionamento “é-um”. Por exemplo, um cão ou um gato “é-um” animal de estimação. Esse relacionamento sempre representa o objective (único) da class (em conjunto com o “princípio da responsabilidade única” ).

    Interfaces , por outro lado, representam resources adicionais de uma class. Eu chamaria isso de relacionamento “é”, como em ” Foo é descartável”, daí a interface IDisposable em C #.

    Interfaces

    • Define o contrato entre dois módulos. Não pode ter qualquer implementação.
    • A maioria das linguagens permite implementar várias interfaces
    • Modificar uma interface é uma alteração urgente. Todas as implementações precisam ser recompiladas / modificadas.
    • Todos os membros são públicos. Implementações devem implementar todos os membros.
    • Interfaces ajudam no desacoplamento. Você pode usar estruturas simuladas para ridicularizar qualquer coisa por trás de uma interface
    • Interfaces normalmente indicam um tipo de comportamento
    • Implementações de interface são desacopladas / isoladas umas das outras

    Classes Base

    • Permite que você adicione alguma implementação padrão que você obtém gratuitamente por derivação
    • Exceto C ++, você só pode derivar de uma class. Mesmo se puder de várias classs, geralmente é uma má ideia.
    • Mudar a class base é relativamente fácil. Derivações não precisam fazer nada de especial
    • Classes base podem declarar funções protegidas e públicas que podem ser acessadas por derivações
    • Resumo As classs básicas não podem ser ridicularizadas facilmente como interfaces
    • Classes base normalmente indicam hierarquia de tipos (IS A)
    • Derivações de class podem vir a depender de algum comportamento básico (ter conhecimento intrincado da implementação pai). As coisas podem ficar confusas se você fizer uma mudança na implementação básica de um cara e quebrar os outros.

    Em geral, você deve favorecer interfaces sobre classs abstratas. Uma razão para usar uma class abstrata é se você tiver uma implementação comum entre classs concretas. É claro, você ainda deve declarar uma interface (IPet) e ter uma class abstrata (PetBase) para implementar essa interface. Usando interfaces pequenas e distintas, você pode usar múltiplos para melhorar ainda mais a flexibilidade. As interfaces permitem o máximo de flexibilidade e portabilidade dos tipos através dos limites. Ao passar referências através dos limites, sempre passe a interface e não o tipo concreto. Isso permite que o destinatário determine a implementação concreta e forneça a máxima flexibilidade. Isso é absolutamente verdadeiro quando se programa em um modo TDD / BDD.

    A Gangue dos Quatro declarou em seu livro “Como a inheritance expõe uma subclass a detalhes da implementação de seus pais, muitas vezes é dito que ‘a inheritance quebra o encapsulamento”. Eu acredito que isto seja verdade.

    Isso é bastante específico para o .NET, mas o livro Framework Design Guidelines argumenta que, em geral, as classs fornecem mais flexibilidade em uma estrutura em evolução. Depois que uma interface é enviada, você não terá a chance de alterá-la sem quebrar o código que usou essa interface. Com uma class, no entanto, você pode modificá-lo e não quebrar o código vinculado a ele. Desde que você faça as modificações certas, o que inclui a adição de novas funcionalidades, você poderá estender e evoluir seu código.

    Krzysztof Cwalina diz na página 81:

    Ao longo das três versões do .NET Framework, falei sobre essa diretriz com alguns desenvolvedores de nossa equipe. Muitos deles, incluindo aqueles que inicialmente discordaram das diretrizes, disseram que se arrependeram de ter enviado alguma API como interface. Eu não ouvi falar de nenhum caso em que alguém tenha se arrependido de ter enviado uma aula.

    Dito isto, certamente há um lugar para interfaces. Como uma diretriz geral, sempre forneça uma implementação de class base abstrata de uma interface, para nada mais, como um exemplo de uma maneira de implementar a interface. No melhor dos casos, essa class base economizará muito trabalho.

    Juan,

    Eu gosto de pensar em interfaces como uma maneira de caracterizar uma class. Uma determinada class de raça de cão, digamos um YorkshireTerrier, pode ser um descendente da class de cão pai, mas também implementa IFurry, IStubby e IYippieDog. Então a class define o que a class é, mas a interface nos diz coisas sobre ela.

    A vantagem disso é que eu posso, por exemplo, reunir todos os IYippieDog’s e jogá-los na minha coleção Ocean. Portanto, agora posso alcançar um determinado conjunto de objects e encontrar os que atendem aos critérios que estou observando sem inspecionar a class muito de perto.

    Eu acho que as interfaces realmente devem definir um subconjunto do comportamento público de uma class. Se definir todo o comportamento público para todas as classs que implementam, geralmente não precisará existir. Eles não me dizem nada de útil.

    Este pensamento vai contra a idéia de que toda class deve ter uma interface e você deve codificar na interface. Tudo bem, mas você acaba com muitas interfaces de um para um e torna as coisas confusas. Eu entendo que a idéia é que realmente não custa nada para fazer e agora você pode trocar as coisas dentro e fora com facilidade. No entanto, acho que raramente faço isso. Na maioria das vezes, estou apenas modificando a class existente e tendo exatamente os mesmos problemas que sempre fiz se a interface pública dessa class precisar mudar, exceto que agora tenho que alterá-la em dois lugares.

    Então, se você pensa como eu, você definitivamente diria que Gato e Cão são IPettable. É uma caracterização que combina com os dois.

    A outra parte disso é que eles devem ter a mesma class base? A questão é que eles precisam ser amplamente tratados como a mesma coisa. Certamente eles são ambos animais, mas isso se encheckbox como vamos usá-los juntos.

    Digamos que eu queira reunir todas as classs de animais e colocá-las no meu contêiner da Arca.

    Ou eles precisam ser Mamíferos? Talvez precisemos de algum tipo de fábrica de ordenha animal cruzada?

    Será que eles precisam estar ligados? É suficiente apenas saber que ambos são IPettable?

    Muitas vezes sinto o desejo de derivar toda uma hierarquia de classs quando realmente preciso apenas de uma class. Eu faço isso em antecipação, algum dia eu poderia precisar e geralmente nunca o faço. Mesmo quando eu faço, eu geralmente acho que tenho que fazer muita coisa para consertar. Isso porque a primeira aula que estou criando não é o Cachorro, eu não tenho essa sorte, mas sim o Ornitorrinco. Agora toda a minha hierarquia de classs é baseada no caso bizarro e eu tenho um monte de código desperdiçado.

    Você também pode achar que em algum momento nem todos os gatos são imutáveis ​​(como aquele que não tem pêlos). Agora você pode mover essa interface para todas as classs derivadas que se encheckboxm. Você vai descobrir que uma mudança muito menor que de repente os gatos não são mais derivados de PettableBase.

    Aqui está a definição básica e simples da interface e da class base:

    • Classe base = inheritance de objects.
    • Interface = inheritance funcional.

    Felicidades

    Eu recomendo usar composição em vez de inheritance sempre que possível. Use interfaces, mas use objects de membro para implementação de base. Dessa forma, você pode definir uma fábrica que construa seus objects para se comportarem de uma determinada maneira. Se você quiser mudar o comportamento, então você cria um novo método de fábrica (ou fábrica abstrata) que cria diferentes tipos de sub-objects.

    Em alguns casos, você pode descobrir que seus objects primários não precisam de interfaces, se todos os comportamentos mutáveis ​​forem definidos em objects auxiliares.

    Então, ao invés de IPet ou PetBase, você pode acabar com um Pet que tenha um parâmetro IFurBehavior. O parâmetro IFurBehavior é definido pelo método CreateDog () do PetFactory. É esse parâmetro que é chamado pelo método shed ().

    Se você fizer isso, verá que seu código é muito mais flexível e a maioria de seus objects simples lida com comportamentos muito básicos em todo o sistema.

    Eu recomendo este padrão mesmo em idiomas de inheritance múltipla.

    Explicou bem neste artigo do Java World

    Pessoalmente, costumo usar interfaces para definir interfaces – ou seja, partes do design do sistema que especificam como algo deve ser acessado.

    Não é incomum que eu tenha uma class implementando 1 ou mais interfaces.

    Aulas abstratas que uso como base para outra coisa.

    O seguinte é um extrato do artigo do artigo acima mencionado JavaWorld.com, autor Tony Sintes, 20/04/01


    Interface vs. class abstrata

    A escolha de interfaces e classs abstratas não é uma proposição ou. Se você precisar alterar seu design, crie uma interface. No entanto, você pode ter classs abstratas que fornecem algum comportamento padrão. As classs abstratas são excelentes candidatos dentro de estruturas de aplicativos.

    Classes abstratas permitem que você defina alguns comportamentos; eles forçam suas subclasss a fornecerem outras. Por exemplo, se você tiver uma estrutura de aplicativo, uma class abstrata poderá fornecer serviços padrão, como manipulação de events e mensagens. Esses serviços permitem que seu aplicativo se conecte à sua estrutura de aplicativos. No entanto, há algumas funcionalidades específicas do aplicativo que somente seu aplicativo pode executar. Tal funcionalidade pode include tarefas de boot e desligamento, que geralmente são dependentes de aplicativos. Portanto, em vez de tentar definir esse comportamento, a class base abstrata pode declarar methods abstratos de desligamento e boot. A class base sabe que precisa desses methods, mas uma class abstrata permite que sua class admita que não sabe como executar essas ações; só sabe que deve iniciar as ações. Quando é hora de iniciar, a class abstrata pode chamar o método de boot. Quando a class base chama esse método, Java chama o método definido pela class filha.

    Muitos desenvolvedores esquecem que uma class que define um método abstrato também pode chamar esse método. Classes abstratas são uma excelente maneira de criar hierarquias de inheritance planejadas. Eles também são uma boa escolha para classs não-mortas em hierarquias de classs.

    Classe vs. interface

    Alguns dizem que você deve definir todas as classs em termos de interfaces, mas acho que a recomendação parece um pouco extrema. Eu uso interfaces quando vejo que algo no meu design vai mudar com freqüência.

    Por exemplo, o padrão Strategy permite que você troque novos algoritmos e processos em seu programa sem alterar os objects que os utilizam. Um reprodutor de mídia pode saber como reproduzir CDs, MP3s e arquivos WAV. Claro, você não quer codificar esses algoritmos de reprodução no player; Isso tornará difícil adicionar um novo formato como o AVI. Além disso, seu código estará repleto de instruções de casos inúteis. E para adicionar insulto à injúria, você precisará atualizar essas declarações caso cada vez que você adicionar um novo algoritmo. Tudo sumdo, esta não é uma maneira muito orientada a objects para programar.

    Com o padrão Strategy, você pode simplesmente encapsular o algoritmo por trás de um object. Se você fizer isso, poderá fornecer novos plug-ins de mídia a qualquer momento. Vamos chamar a class de plug-ins MediaStrategy. Esse object teria um método: playStream (Stream s). Então, para adicionar um novo algoritmo, simplesmente estendemos nossa class de algoritmos. Agora, quando o programa encontra o novo tipo de mídia, ele simplesmente delega a execução do stream à nossa estratégia de mídia. Naturalmente, você precisará de algum encanamento para instanciar corretamente as estratégias de algoritmo necessárias.

    Este é um excelente lugar para usar uma interface. Usamos o padrão de estratégia, que indica claramente um lugar no design que será alterado. Assim, você deve definir a estratégia como uma interface. Você deve geralmente favorecer interfaces sobre inheritance quando você quer que um object tenha um certo tipo; neste caso, o MediaStrategy. Confiar na inheritance para identidade de tipo é perigoso; Ele bloqueia você em uma hierarquia de inheritance específica. Java não permite inheritance múltipla, então você não pode estender algo que lhe dê uma implementação útil ou mais identidade de tipo.

    Lembre-se também de não ser varrido em OO ( ver blog ) e sempre modelar objects com base no comportamento necessário, se você estivesse projetando um aplicativo em que o único comportamento necessário era um nome genérico e uma espécie para um animal, então você só precisaria Uma class Animal com uma propriedade para o nome, em vez de milhões de classs para todos os animais possíveis no mundo.

    Eu tenho uma regra básica

    Funcionalidade: provavelmente diferente em todas as partes: Interface.

    Dados e funcionalidade, as partes serão basicamente as mesmas, partes diferentes: class abstrata.

    Dados e funcionalidade, na verdade funcionando, se estendidos apenas com pequenas alterações: class comum (concreta)

    Dados e funcionalidade, sem alterações planejadas: class ordinária (concreta) com modificador final.

    Dados e talvez funcionalidade: somente leitura: membros enum.

    Isso é muito rude e está pronto e não é estritamente definido, mas há um espectro de interfaces onde tudo é destinado a ser alterado para enums, onde tudo é corrigido um pouco como um arquivo somente leitura.

    Interfaces devem ser pequenas. Muito pequeno. Se você está realmente dividindo seus objects, provavelmente suas interfaces conterão apenas alguns methods e propriedades muito específicos.

    Classes abstratas são atalhos. Existem coisas que todos os derivados do PetBase compartilham que você pode codificar uma vez e ser feito? Se sim, então é hora de uma aula abstrata.

    Classes abstratas também são limitantes. Enquanto eles fornecem um ótimo atalho para a produção de objects filhos, qualquer object pode implementar apenas uma class abstrata. Muitas vezes, acho isso uma limitação das classs abstratas, e é por isso que uso muitas interfaces.

    Classes abstratas podem conter várias interfaces. Sua class abstrata PetBase pode implementar IPet (animais de estimação têm proprietários) e IDigestion (animais de estimação comem, ou pelo menos deveriam). No entanto, o PetBase provavelmente não implementará o IMammal, já que nem todos os animais de estimação são mamíferos e nem todos os mamíferos são animais de estimação. Você pode adicionar um MammalPetBase que estenda o PetBase e adicione o IMammal. FishBase poderia ter PetBase e adicionar IFish. IFish teria ISwim e IUnderwaterBreather como interfaces.

    Sim, meu exemplo é extremamente complicado para o exemplo simples, mas isso é parte da grande coisa sobre como interfaces e classs abstratas trabalham juntas.

    O caso de Classes Base sobre Interfaces foi bem explicado nas Diretrizes de Codificação Submain .NET:

    Classes Base versus Interfaces Um tipo de interface é uma descrição parcial de um valor, potencialmente suportado por muitos tipos de object. Use classs base em vez de interfaces sempre que possível. De uma perspectiva de versionamento, as classs são mais flexíveis que as interfaces. Com uma class, você pode enviar a versão 1.0 e, em seguida, na versão 2.0, adicionar um novo método à class. Contanto que o método não seja abstrato, quaisquer classs derivadas existentes continuarão a funcionar inalteradas.

    Como as interfaces não suportam a inheritance de implementação, o padrão que se aplica a classs não se aplica a interfaces. Adicionar um método a uma interface é equivalente a adicionar um método abstrato a uma class base; qualquer class que implementa a interface será interrompida porque a class não implementa o novo método. Interfaces são apropriadas nas seguintes situações:

    1. Várias classs não relacionadas desejam suportar o protocolo.
    2. Essas classs já estabeleceram classs base (por exemplo, alguns são controles de interface do usuário (UI) e alguns são serviços XML da Web).
    3. A agregação não é apropriada ou praticável. Em todas as outras situações, a inheritance de classs é um modelo melhor.

    Uma diferença importante é que você só pode herdar uma class base, mas pode implementar várias interfaces. Então você só quer usar uma class base se tiver absoluta certeza de que não precisará herdar uma class base diferente. Além disso, se você achar que sua interface está ficando grande, então você deve começar a dividir em algumas partes lógicas que definem a funcionalidade independente, já que não há regras que sua class não possa implementar todas elas (ou que você possa definir um diferente interface que apenas herda todos eles para agrupá-los).

    Quando comecei a aprender sobre programação orientada a objects, cometi o erro fácil e provavelmente comum de usar a inheritance para compartilhar um comportamento comum – mesmo quando esse comportamento não era essencial para a natureza do object.

    Para construir um exemplo muito usado nesta questão em particular, há muitas coisas que são petinhas – namoradas, carros, cobertores felpudos … – então eu poderia ter tido uma class Petable que fornecesse esse comportamento comum, e várias classs herdando a partir dele.

    No entanto, ser petable não faz parte da natureza de qualquer um desses objects. Existem conceitos muito mais importantes que são essenciais à sua natureza – a namorada é uma pessoa, o carro é um veículo terrestre, o gato é um mamífero …

    Os comportamentos devem ser atribuídos primeiro a interfaces (incluindo a interface padrão da class) e promovidos a uma class base somente se forem (a) comuns a um grande grupo de classs que são subconjuntos de uma class maior – no mesmo sentido que “gato” e “pessoa” são subconjuntos de “mamífero”.

    A pegadinha é que, depois de entender o design orientado a objects de maneira suficientemente melhor do que eu, você normalmente fará isso automaticamente, mesmo sem pensar nisso. Assim, a verdade nua da afirmação “código para uma interface, não uma class abstrata” torna-se tão óbvia que você tem dificuldade em acreditar que alguém se importaria em dizê-la – e começar a tentar ler outros significados nela.

    Outra coisa que eu acrescentaria é que se uma class é puramente abstrata – sem membros ou methods não-abstratos, não-herdados, expostos a filho, pai ou cliente – então por que é uma class? Ele poderia ser substituído, em alguns casos, por uma interface e, em outros casos, pela Null.

    Fonte : http://jasonroell.com/2014/12/09/interfaces-vs-abstract-classs-what-should-you-use/

    C # é uma linguagem maravilhosa que amadureceu e evoluiu nos últimos 14 anos. Isso é ótimo para nós, desenvolvedores, porque uma linguagem madura nos fornece uma infinidade de resources de linguagem que estão à nossa disposição.

    No entanto, com muito poder se torna muita responsabilidade. Alguns desses resources podem ser mal utilizados ou, às vezes, é difícil entender por que você escolheria usar um recurso em vez de outro. Ao longo dos anos, um recurso com o qual muitos desenvolvedores lutam é quando escolhem usar uma interface ou optar por usar uma class abstrata. Ambos têm vantagens e desvantagens e a hora e o local corretos para usar cada um. Mas como nós decidimos ???

    Ambos fornecem reutilização de funcionalidade comum entre tipos. The most obvious difference right away is that interfaces provide no implementation for their functionality whereas abstract classs allow you to implement some “base” or “default” behavior and then have the ability to “override” this default behavior with the classs derived types if necessary.

    This is all well and good and provides for great reuse of code and adheres to the DRY (Don’t Repeat Yourself) principle of software development. Abstract classs are great to use when you have an “is a” relationship.

    For example: A golden retriever “is a” type of dog. So is a poodle. They both can bark, as all dogs can. However, you might want to state that the poodle park is significantly different than the “default” dog bark. Therefor, it could make sense for you to implement something as follows:

     public abstract class Dog { public virtual void Bark() { Console.WriteLine("Base Class implementation of Bark"); } } public class GoldenRetriever : Dog { // the Bark method is inherited from the Dog class } public class Poodle : Dog { // here we are overriding the base functionality of Bark with our new implementation // specific to the Poodle class public override void Bark() { Console.WriteLine("Poodle's implementation of Bark"); } } // Add a list of dogs to a collection and call the bark method. void Main() { var poodle = new Poodle(); var goldenRetriever = new GoldenRetriever(); var dogs = new List(); dogs.Add(poodle); dogs.Add(goldenRetriever); foreach (var dog in dogs) { dog.Bark(); } } // Output will be: // Poodle's implementation of Bark // Base Class implementation of Bark // 

    As you can see, this would be a great way to keep your code DRY and allow for the base class implementation be called when any of the types can just rely on the default Bark instead of a special case implementation. The classs like GoldenRetriever, Boxer, Lab could all could inherit the “default” (bass class) Bark at no charge just because they implement the Dog abstract class.

    But I’m sure you already knew that.

    You are here because you want to understand why you might want to choose an interface over an abstract class or vice versa. Well one reason you may want to choose an interface over an abstract class is when you don’t have or want to prevent a default implementation. This is usually because the types that are implementing the interface not related in an “is a” relationship. Actually, they don’t have to be related at all except for the fact that each type “is able” or has “the ablity” to do something or have something.

    Now what the heck does that mean? Well, for example: A human is not a duck…and a duck is not a human. Pretty obvious. However, both a duck and a human have “the ability” to swim (given that the human passed his swimming lessons in 1st grade 🙂 ). Also, since a duck is not a human or vice versa, this is not an “is a” realationship, but instead an “is able” relationship and we can use an interface to illustrate that:

     // Create ISwimable interface public interface ISwimable { public void Swim(); } // Have Human implement ISwimable Interface public class Human : ISwimable public void Swim() { //Human's implementation of Swim Console.WriteLine("I'm a human swimming!"); } // Have Duck implement ISwimable interface public class Duck: ISwimable { public void Swim() { // Duck's implementation of Swim Console.WriteLine("Quack! Quack! I'm a Duck swimming!") } } //Now they can both be used in places where you just need an object that has the ability "to swim" public void ShowHowYouSwim(ISwimable somethingThatCanSwim) { somethingThatCanSwim.Swim(); } public void Main() { var human = new Human(); var duck = new Duck(); var listOfThingsThatCanSwim = new List(); listOfThingsThatCanSwim.Add(duck); listOfThingsThatCanSwim.Add(human); foreach (var something in listOfThingsThatCanSwim) { ShowHowYouSwim(something); } } // So at runtime the correct implementation of something.Swim() will be called // Output: // Quack! Quack! I'm a Duck swimming! // I'm a human swimming! 

    Using interfaces like the code above will allow you to pass an object into a method that “is able” to do something. The code doesn’t care how it does it…All it knows is that it can call the Swim method on that object and that object will know which behavior take at run-time based on its type.

    Once again, this helps your code stay DRY so that you would not have to write multiple methods that are calling the object to preform the same core function (ShowHowHumanSwims(human), ShowHowDuckSwims(duck), etc.)

    Using an interface here allows the calling methods to not have to worry about what type is which or how the behavior is implemented. It just knows that given the interface, each object will have to have implemented the Swim method so it is safe to call it in its own code and allow the behavior of the Swim method be handled within its own class.

    Resumo:

    So my main rule of thumb is use an abstract class when you want to implement a “default” functionality for a class hierarchy or/and the classs or types you are working with share a “is a” relationship (ex. poodle “is a” type of dog).

    On the other hand use an interface when you do not have an “is a” relationship but have types that share “the ability” to do something or have something (ex. Duck “is not” a human. However, duck and human share “the ability” to swim).

    Another difference to note between abstract classs and interfaces is that a class can implement one to many interfaces but a class can only inherit from ONE abstract class (or any class for that matter). Yes, you can nest classs and have an inheritance hierarchy (which many programs do and should have) but you cannot inherit two classs in one derived class definition (this rule applies to C#. In some other languages you are able to do this, usually only because of the lack of interfaces in these languages).

    Also remember when using interfaces to adhere to the Interface Segregation Principle (ISP). ISP states that no client should be forced to depend on methods it does not use. For this reason interfaces should be focused on specific tasks and are usually very small (ex. IDisposable, IComparable ).

    Another tip is if you are developing small, concise bits of functionality, use interfaces. If you are designing large functional units, use an abstract class.

    Hope this clears things up for some people!

    Also if you can think of any better examples or want to point something out, please do so in the comments below!

    Previous comments about using abstract classs for common implementation is definitely on the mark. One benefit I haven’t seen mentioned yet is that the use of interfaces makes it much easier to implement mock objects for the purpose of unit testing. Defining IPet and PetBase as Jason Cohen described enables you to mock different data conditions easily, without the overhead of a physical database (until you decide it’s time to test the real thing).

    Don’t use a base class unless you know what it means, and that it applies in this case. If it applies, use it, otherwise, use interfaces. But note the answer about small interfaces.

    Public Inheritance is overused in OOD and expresses a lot more than most developers realize or are willing to live up to. See the Liskov Substitutablity Principle

    In short, if A “is a” B then A requires no more than B and delivers no less than B, for every method it exposes.

    Conceptually, an Interface is used to formally and semi-formally define a set of methods that an object will provide. Formally means a set of method names and signatures, semi-formally means human readable documentation associated with those methods. Interfaces are only descriptions of an API (after all, API stands for Application Programmer Interface ), they can’t contain any implementation, and it’s not possible to use or run an Interface. They only make explicit the contract of how you should interact with an object.

    Classes provide an implementation, they can declare that they implement zero, one or more Interfaces. If a Class is intended to be inherited, the convention is to prefix the Class name with “Base”.

    There is a distinction between a Base Class and an Abstract Base Classes (ABC). ABCs mix interface and implementation together. Abstract outside of computer programming means “summary”, that is “Abstract == Interface”. An Abstract Base Class can then describe both an interface, as well as an empty, partial or complete implementation that is intended to be inherited.

    Opinions on when to use Interfaces versus Abstract Base Classes versus just Classes is going to vary wildly based on both what you are developing, and which language you are developing in. Interfaces are often associated only with statically typed languages such as Java or C#, but dynamically typed languages can also have Interfaces and Abstract Base Classes. In Python for example, the distinction is made clear between a Class, which declares that it implements an Interface, and an object, which is an instance of a Class, and is said to provide that Interface. It’s possible in a dynamic language that two objects that are both instances of the same Class, can declare that they provide completely different interfaces. In Python this is only possible for object attributes, while methods are shared state between all objects of a Class. However in Ruby, objects can have per-instance methods, so it’s possible that the Interface between two objects of the same Class can vary as much as the programmer desires (however, Ruby doesn’t have any explicit way of declaring Interfaces).

    In dynamic languages the Interface to an object is often implicitly assumed, either by introspecting an object and asking it what methods it provides (Look Before You Leap) or preferably by simply attempting to use the desired Interface on an object and catching exceptions if the object doesn’t provide that Interface (Easier to Ask Forgiveness than Permission). This can lead to “false positives” where two Interfaces have the same method name but are semantically different, however the trade-off is that your code is more flexible since you don’t need to over specify up-front to anticipate all possible uses of your code.

    Another option to keep in mind is using the “has-a” relationship, aka “is implemented in terms of” or “composition.” Sometimes this is a cleaner, more flexible way to structure things than using “is-a” inheritance.

    It may not make as much sense logically to say that Dog and Cat both “have” a Pet, but it avoids common multiple inheritance pitfalls:

     public class Pet { void Bathe(); void Train(Trick t); } public class Dog { private Pet pet; public void Bathe() { pet.Bathe(); } public void Train(Trick t) { pet.Train(t); } } public class Cat { private Pet pet; public void Bathe() { pet.Bathe(); } public void Train(Trick t) { pet.Train(t); } } 

    Yes, this example shows that there is a lot of code duplication and lack of elegance involved in doing things this way. But one should also appreciate that this helps to keep Dog and Cat decoupled from the Pet class (in that Dog and Cat do not have access to the private members of Pet), and it leaves room for Dog and Cat to inherit from something else–possibly the Mammal class.

    Composition is preferable when no private access is required and you don’t need to refer to Dog and Cat using generic Pet references/pointers. Interfaces give you that generic reference capability and can help cut down on the verbosity of your code, but they can also obfuscate things when they are poorly organized. Inheritance is useful when you need private member access, and in using it you are committing yourself to highly coupling your Dog and Cat classs to your Pet class, which is a steep cost to pay.

    Between inheritance, composition, and interfaces there is no one way that is always right, and it helps to consider how all three options can be used in harmony. Of the three, inheritance is typically the option that should be used the least often.

    Prefer interfaces over abstract classs

    Rationale, the main points to consider [two already mentioned here] are :

    • Interfaces are more flexible, because a class can implement multiple interfaces. Since Java does not have multiple inheritance, using abstract classs prevents your users from using any other class hierarchy. In general, prefer interfaces when there are no default implementations or state. Java collections offer good examples of this (Map, Set, etc.).
    • Abstract classs have the advantage of allowing better forward compatibility. Once clients use an interface, you cannot change it; if they use an abstract class, you can still add behavior without breaking existing code. If compatibility is a concern, consider using abstract classs.
    • Even if you do have default implementations or internal state, consider offering an interface and an abstract implementation of it . This will assist clients, but still allow them greater freedom if desired [1].
      Of course, the subject has been discussed at length elsewhere [2,3].

    [1] It adds more code, of course, but if brevity is your primary concern, you probably should have avoided Java in the first place!

    [2] Joshua Bloch, Effective Java, items 16-18.

    [3] http://www.codeproject.com/KB/ar

    It depends on your requirements. If IPet is simple enough, I would prefer to implement that. Otherwise, if PetBase implements a ton of functionality you don’t want to duplicate, then have at it.

    The downside to implementing a base class is the requirement to override (or new ) existing methods. This makes them virtual methods which means you have to be careful about how you use the object instance.

    Lastly, the single inheritance of .NET kills me. A naive example: Say you’re making a user control, so you inherit UserControl . But, now you’re locked out of also inheriting PetBase . This forces you to reorganize, such as to make a PetBase class member, instead.

    @Joel: Some languages (eg, C++) allow multiple-inheritance.

    I usually don’t implement either until I need one. I favor interfaces over abstract classs because that gives a little more flexibility. If there’s common behavior in some of the inheriting classs I move that up and make an abstract base class. I don’t see the need for both, since they essentially server the same purpose, and having both is a bad code smell (imho) that the solution has been over-engineered.

    Regarding C#, in some senses interfaces and abstract classs can be interchangeable. However, the differences are: i) interfaces cannot implement code; ii) because of this, interfaces cannot call further up the stack to subclass; and iii) only can abstract class may be inherited on a class, whereas multiple interfaces may be implemented on a class.

    I’ve found that a pattern of Interface > Abstract > Concrete works in the following use-case:

     1. You have a general interface (eg IPet) 2. You have a implementation that is less general (eg Mammal) 3. You have many concrete members (eg Cat, Dog, Ape) 

    The abstract class defines default shared attributes of the concrete classs, yet enforces the interface. Por exemplo:

     public interface IPet{ public boolean hasHair(); public boolean walksUprights(); public boolean hasNipples(); } 

    Now, since all mammals have hair and nipples (AFAIK, I’m not a zoologist), we can roll this into the abstract base class

     public abstract class Mammal() implements IPet{ @override public walksUpright(){ throw new NotSupportedException("Walks Upright not implemented"); } @override public hasNipples(){return true} @override public hasHair(){return true} 

    And then the concrete classs merely define that they walk upright.

     public class Ape extends Mammal(){ @override public walksUpright(return true) } public class Catextends Mammal(){ @override public walksUpright(return false) } 

    This design is nice when there are lots of concrete classs, and you don’t want to maintain boilerplate just to program to an interface. If new methods were added to the interface, it would break all of the resulting classs, so you are still getting the advantages of the interface approach.

    In this case, the abstract could just as well be concrete; however, the abstract designation helps to emphasize that this pattern is being employed.

    An inheritor of a base class should have an “is a” relationship. Interface represents An “implements a” relationship. So only use a base class when your inheritors will maintain the is a relationship.

    Use Interfaces to enforce a contract ACROSS families of unrelated classs. For example, you might have common access methods for classs that represent collections, but contain radically different data ie one class might represent a result set from a query, while the other might represent the images in a gallery. Also, you can implement multiple interfaces, thus allowing you to blend (and signify) the capabilities of the class.

    Use Inheritance when the classs bear a common relationship and therefore have a similair structural and behavioural signature, ie Car, Motorbike, Truck and SUV are all types of road vehicle that might contain a number of wheels, a top speed