Como devo ter explicado a diferença entre uma Interface e uma classe abstrata?

Primeiro Vou dar-te um exemplo.

public interface LoginAuth{
   public String encryptPassword(String pass);
   public void checkDBforUser();
}

Agora, suponha que tem 3 bases de dados na sua aplicação. Em seguida, cada implementação para essa base de dados precisa definir os 2 métodos acima:

public class DBMySQL implements LoginAuth{
          // Needs to implement both methods
}
public class DBOracle implements LoginAuth{
          // Needs to implement both methods
}
public class DBAbc implements LoginAuth{
          // Needs to implement both methods
}

Mas e se o encryptPassword() não for dependente de bases de dados, e for o mesmo para cada classe? Então o acima não seria uma boa abordagem.

Em vez disso, considere esta abordagem:

public abstract class LoginAuth{
   public String encryptPassword(String pass){
            // Implement the same default behavior here 
            // that is shared by all subclasses.
   }

   // Each subclass needs to provide their own implementation of this only:
   public abstract void checkDBforUser();
}

Agora, em cada classe de crianças, só precisamos de implementar um método: método que depende da base de dados. Fiz o meu melhor e espero que isto esclareça as tuas dúvidas.

Nada é perfeito neste mundo. Podem estar à espera de uma abordagem mais prática. Mas depois da sua explicação, pode adicionar estas linhas com uma abordagem ligeiramente diferente.

1. Interfaces são regras (regras porque você deve fornecer uma implementação para eles que você não pode ignorar ou evitar, de modo que eles são impostas, como normas) que funciona como um entendimento comum de documentos entre várias equipes no desenvolvimento de software.

2. Interfaces dar a idéia do que deve ser feito, mas não como ele será feito. Assim, a implementação depende completamente do desenvolvedor, seguindo as regras indicadas (significa a assinatura dada dos métodos).

3. Classes abstratas podem conter declarações abstratas, implementações concretas, ou ambas.

4. Declarações abstratas são como regras a serem seguidas e implementações concretas são como diretrizes (você pode usá-lo como ele é ou você pode ignorá-lo, sobrepondo e dando o seu próprio implementação).

5. Além disso, os métodos com a mesma assinatura podem alterar o comportamento em diferentes contextos são fornecidos como declarações de interface como regras a aplicar em conformidade em diferentes contextos.

Edit: Java 8 facilita a definição de métodos estáticos e predefinidos na interface.

public interface SomeInterfaceOne {

    void usualAbstractMethod(String inputString);

    default void defaultMethod(String inputString){
        System.out.println("Inside SomeInterfaceOne defaultMethod::"+inputString);
    }
}

Agora, quando uma classe irá implementar alguma interface, não é obrigatório fornecer implementação para os métodos predefinidos de interface.

Se temos outra interface com os seguintes métodos:

public interface SomeInterfaceTwo {

    void usualAbstractMethod(String inputString);

    default void defaultMethod(String inputString){
        System.out.println("Inside SomeInterfaceTwo defaultMethod::"+inputString);
    }

}

Java não permite estender várias classes porque resulta no "problema do diamante" onde o compilador não é capaz de decidir qual o método de superclasse a usar. Com os métodos padrão, o problema do diamante vai surgir para interfaces também. Porque se uma classe está implementando ambos

SomeInterfaceOne and SomeInterfaceTwo

E não implementa o método padrão comum, o compilador não pode decidir qual escolher. Para evitar este problema, em java 8 é obrigatório implementar métodos padrão comuns de diferentes interfaces. Se qualquer classe estiver implementando ambas as interfaces acima, ela tem que fornecer implementação para o método defaultMethod() caso contrário compilador irá lançar erro de tempo de compilação.

Fez um bom resumo das diferenças práticas de utilização e implementação, mas não disse nada sobre a diferença de significado.

Uma interface é uma descrição do comportamento que uma classe de implementação terá. A classe de implementação garante, que terá estes métodos que podem ser usados nela. É basicamente um contrato ou uma promessa que a turma tem de fazer.

Uma classe abstracta é uma base para diferentes subclasses que partilham comportamento que não precisa de ser criado repetidamente. As Subclasses devem completar o comportamento e ter a opção de sobrepor o comportamento predefinido (desde que não seja definido como final ou private).

Irá encontrar bons exemplos no Pacote java.util que inclui interfaces como List e classes abstractas como AbstractList que já implementa a interface. A documentação oficial descreve o AbstractList da seguinte forma:

Esta classe fornece um esqueleto. implementação da interface de lista para minimizar o esforço necessário para implementar esta interface apoiada por um armazenamento de dados de "acesso aleatório" (como um array).

Uma interface consiste em variáveis de singleton (public static final) e métodos públicos abstractos. Nós normalmente prefiro usar uma interface em tempo real quando sabemos o que fazer, mas não sei como fazê-lo.

Este conceito pode ser melhor compreendido pelo exemplo:

Considere uma classe de pagamento. O pagamento pode ser feito de muitas maneiras, como PayPal, cartão de crédito, etc. Por isso, normalmente tomamos o pagamento como a nossa interface que contém um método makePayment() e CreditCard e PayPal são as duas classes de implementação.

public interface Payment
{
    void makePayment();//by default it is a abstract method
}
public class PayPal implements Payment
{
    public void makePayment()
    {
        //some logic for PayPal payment
        //e.g. Paypal uses username and password for payment
    }
}
public class CreditCard implements Payment
{
    public void makePayment()
    {
        //some logic for CreditCard payment
        //e.g. CreditCard uses card number, date of expiry etc...
    }
}

No exemplo acima, o CreditCard e o PayPal são duas classes /estratégias de implementação. Uma Interface também nos permite o conceito de herança múltipla em Java que não pode ser realizado por uma classe abstrata.

Escolhemos uma classe abstracta quando há algumas características para as quais sabemos o que fazer, e outras características que sabemos como executar.

Considere o seguinte exemplo:

public abstract class Burger
{
    public void packing()
    {
        //some logic for packing a burger
    }
    public abstract void price(); //price is different for different categories of burgers
}
public class VegBerger extends Burger
{
    public void price()
    {
        //set price for a veg burger.
    }
}
public class NonVegBerger extends Burger
{
    public void price()
    {
        //set price for a non-veg burger.
    }
}

Se adicionamos métodos (concretos / abstratos) no futuro a uma determinada classe abstrata, então a classe de implementação não precisará de uma alteração do seu código. No entanto, se adicionarmos métodos em uma interface no futuro, devemos adicionar implementações a todas as classes que implementaram essa interface, caso contrário compilar erros de tempo ocorrem.

Existem outras diferenças, mas estas são grandes, que podem ter sido o que o seu entrevistador esperava . Espero que tenha sido útil.

Todas as suas declarações são válidas exceto a sua primeira declaração (após a versão Java 8)):

Os Métodos de uma interface Java são implicitamente abstratos e não podem ter implementações

Da documentação Página:

Uma interface é um tipo de referência, semelhante a uma classe, que pode conter apenas constantes, assinaturas de métodos, métodos predefinidos, métodos estáticos e tipos aninhados

Apenas existem corpos metodológicos. para métodos padrão e métodos estáticos.

métodos predefinidos:

Uma interface pode ter métodos predefinidos , mas são diferentes dos métodos abstractos em classes abstractas.

Os métodos predefinidos permitem-lhe adicionar novas funcionalidades às interfaces das suas bibliotecas e assegurar a compatibilidade binária com o código escrito para as versões mais antigas dessas interfaces.

Quando Extender uma interface que contém um método por omissão, poderá fazer

1. não mencione o método por omissão, que permite à sua interface extendida herdar o método por omissão.
2. Redeclarar o método padrão, o que o torna abstract.
3. Redefine o método por omissão, que se sobrepõe a ele.

Métodos Estáticos:

Para além dos métodos predefinidos, pode definir métodos estáticos nas interfaces. (Um método estático é um método que está associado com a classe em que é definido em vez de com objecto. Cada instância da classe compartilha seus métodos estáticos.)

Isto torna mais fácil para si organizar métodos auxiliares nas suas bibliotecas;

Exemplo de código na página de documentação sobre interface tendo static e default métodos.

import java.time.*;

public interface TimeClient {
    void setTime(int hour, int minute, int second);
    void setDate(int day, int month, int year);
    void setDateAndTime(int day, int month, int year,
                               int hour, int minute, int second);
    LocalDateTime getLocalDateTime();

    static ZoneId getZoneId (String zoneString) {
        try {
            return ZoneId.of(zoneString);
        } catch (DateTimeException e) {
            System.err.println("Invalid time zone: " + zoneString +
                "; using default time zone instead.");
            return ZoneId.systemDefault();
        }
    }

    default ZonedDateTime getZonedDateTime(String zoneString) {
        return ZonedDateTime.of(getLocalDateTime(), getZoneId(zoneString));
    }
}

Utilize as directrizes abaixo para escolher se deve usar uma interface ou uma classe abstracta.

Interface:

1. para definir um Contrato ( De preferência apátridas - quero dizer, Sem Variáveis )
2. ligar classes não relacionadas comtem uma capacidades.
3. declarar variáveis constantes públicas(estado imutável)

Classe abstracta:

1. Partilhar o código entre várias classes estreitamente relacionadas. Estabelece é um relação.

2. Compartilhar estado comum entre classes relacionadas ( estado pode ser modificado em concreto classes)

Lugares relacionados:

Interface / Classe abstracta (general OO)

Implementos vs extends: quando usar? Qual é a diferença?

Passando por estes exemplos, você pode entender que

classes independentes podem ter capacidades através da interface, mas classes relacionadas mudam o comportamento através da extensão de classes de base.

Diferença entre a classe Abstact e a interface

1. classes Abstractas versus interfaces em Java 8
2. Diferença Conceptual:

Métodos predefinidos da Interface em Java 8

1. O Que é o Método Padrão?
2. ForEach method compilation error solved using Default Method
3. Método Padrão e múltiplos problemas de ambiguidade da herança
4. pontos importantes sobre os métodos predefinidos da interface java:

Java Método Estático Da Interface

1. Java Interface Static Method, code example, static method vs default method
2. pontos importantes sobre o método estático da interface java:

Interfaces Funcionais Java

---

---

Classes Abstractas versus interfaces em Java 8

As alterações da interface Java 8 incluem métodos estáticos e métodos predefinidos em interface. Antes do Java 8, poderíamos ter apenas declarações de método em interface. Mas de Java 8, podemos ter métodos padrão e métodos estáticos nas interfaces.

Depois de introduzir o método padrão, parece que as interfaces e as classes abstratas são as mesmas. No entanto, continuam a ser conceitos diferentes em Java 8.

A classe abstracta pode definir construtor. São mais estruturados e pode ter um estado associado a eles. Enquanto em contraste, default o método só pode ser aplicado em termos de Invocação de outros métodos de interface, sem referência a uma execução específica estado. Por conseguinte, tanto a utilização para fins diferentes como a escolha entre dois realmente depende do contexto do cenário.

Diferença Conceptual:

As classes Abstractas são válidas para implementações esqueléticas (isto é, parciais) de interfaces, mas não devem existir sem uma interface correspondente.

Então, quando as classes abstratas são efetivamente reduzidas para serem de baixa visibilidade, implementações esqueléticas de interfaces, podem os métodos padrão tirar isso como então? Decididamente, Não! A implementação de interfaces quase sempre requer algumas ou todas as ferramentas de construção de classes que os métodos padrão não possuem. E se alguma interface não o fizer, é claramente um caso especial, que não deve levá-lo para o mau caminho.

Métodos predefinidos da Interface em Java 8

Java 8 introduz "método predefinido " ou (métodos Defender) nova funcionalidade, que permite ao programador adicionar novos métodos às Interfaces sem quebrar a implementação existente destas Interface. Ele fornece flexibilidade para permitir a Interface definir a implementação que irá usar como padrão na situação em que uma classe concreta não fornece uma implementação para esse método.

Consideremos um pequeno exemplo para entender como funciona:

public interface OldInterface {
    public void existingMethod();
 
    default public void newDefaultMethod() {
        System.out.println("New default method"
               + " is added in interface");
    }
}

A seguinte classe irá compilar com sucesso em Java JDK 8,

public class OldInterfaceImpl implements OldInterface {
    public void existingMethod() {
     // existing implementation is here…
    }
}

Se criar uma instância de OldInterfaceImpl:

OldInterfaceImpl obj = new OldInterfaceImpl ();
// print “New default method add in interface”
obj.newDefaultMethod(); 

---

Método Por Omissão:

Predefinição os métodos nunca são finais, não podem ser sincronizados e não podem anular os métodos do objecto. Eles são sempre públicos, que severamente limita a capacidade de escrever métodos curtos e reutilizáveis.

Os métodos predefinidos podem ser fornecidos a uma Interface sem afectar as Classes de execução, uma vez que inclui uma implementação. Se cada método adicionado em uma Interface definida com a implementação, então nenhuma classe de implementação é afetada. Uma classe de implementação pode sobrepor a implementação predefinida fornecido pela Interface.

Os métodos predefinidos permitem adicionar uma nova funcionalidade às Interfaces existentes sem quebrar a implementação mais antiga destas Interfaces.

Quando extendemos uma interface que contém um método padrão, podemos executar a seguir,

1. não sobrepõe o método por omissão e herdará o método por omissão.
2. sobrepor o método por omissão semelhante a outros métodos que substituímos em subclasse.
3. Redeclarar predefinição método como abstracto, que força a subclasse a cancela-o.

---

ForEach method compilation error solved using Default Method

Para Java 8, as coleções JDK foram ampliadas e o método forEach é adicionado a toda a coleção (que funciona em conjunto com lambdas). Com a maneira convencional, o código parece abaixo,

public interface Iterable<T> {
    public void forEach(Consumer<? super T> consumer);
}

Uma Vez Que este resultado resulta em cada classe de execução com erros de compilação, por conseguinte, um método por omissão adicionado com um necessário implementação para que a implementação existente não seja alterada.

A Interface iterável com o método por omissão está em baixo,

public interface Iterable<T> {
    public default void forEach(Consumer
                   <? super T> consumer) {
        for (T t : this) {
            consumer.accept(t);
        }
    }
}

Foi utilizado o mesmo mecanismo para adicionar Stream na Interface JDK sem quebrar as Classes de execução.

---

Método por omissão e múltiplos problemas de ambiguidade da herança

Uma vez que a classe java pode implementar várias Interfaces e cada Interface pode definir o método padrão com o mesmo método assinatura, portanto, os métodos herdados podem entrar em conflito uns com os outros.

Considere abaixo o exemplo,

public interface InterfaceA {  
       default void defaultMethod(){  
           System.out.println("Interface A default method");  
    }  
}
 
public interface InterfaceB {
   default void defaultMethod(){
       System.out.println("Interface B default method");
   }
}
 
public class Impl implements InterfaceA, InterfaceB  {
}

O código acima não será compilado com o seguinte erro,

Java: a classe Impl herda valores por omissão não relacionados para o defaultMethod () de tipos InterfaceA e InterfaceB

Para corrigir esta classe, precisamos de fornecer a implementação do método padrão:

public class Impl implements InterfaceA, InterfaceB {
    public void defaultMethod(){
    }
}

Além disso, se quisermos invocar a implementação por omissão desde por qualquer Interface super ao invés de nossa própria implementação, podemos fazê-lo da seguinte forma,

public class Impl implements InterfaceA, InterfaceB {
    public void defaultMethod(){
        // existing code here..
        InterfaceA.super.defaultMethod();
    }
}

Podemos escolher qualquer implementação padrão ou ambos como parte do nosso novo método.

Pontos importantes sobre os métodos predefinidos da interface java:

1. Os métodos predefinidos da interface Java ajudar-nos-ão a estender as interfaces sem ter medo de quebrar as classes de implementação.
2. Os métodos predefinidos da interface Java têm uma ponte para as diferenças entre interfaces e aulas abstratas.
3. Os métodos predefinidos da interface Java 8 ajudar-nos-ão a evitar classes de utilitários, como todos os métodos da classe Collections podem ser fornecidos nas próprias interfaces.
4. Os métodos predefinidos da interface Java ajudar-nos-ão a remover as classes de implementação base, podemos fornecer a implementação predefinida e as classes de implementação podem escolher qual substituir.
Uma das principais razões para introduzir métodos predefinidos nas interfaces é melhorar as colecções API em Java 8 para suportar expressões lambda.
5. Se qualquer classe na hierarquia tem um método com a mesma assinatura, então os métodos padrão tornam-se irrelevantes. Um método padrão não pode substituir um método a partir de java.idioma.Objecto. O raciocínio é muito simples, é porque o objeto é a classe base para todas as classes java. Então, mesmo que tenhamos métodos de classe de objetos definidos como métodos padrão em interfaces, isso será inútil porque método de classe de objeto sempre será usado. É por isso que evitar confusão, não podemos ter métodos padrão que estão sobrepondo métodos de classe de objetos.
6. Os métodos padrão da interface Java também são referidos como métodos de defesa ou métodos de extensão Virtual.

Relação De Recursos:

1. Interface com os métodos predefinidos vs Classe Abstract em Java 8
2. classe abstrata versus interface na era JDK 8
3. evolução da Interface via extensão virtual métodos

---

Java Interface Static Method

Java Interface Static Method, code example, static method vs default method

Java interface static method is similar to default method except that we can't override them in the implementation classes. Esta característica nos ajuda a evitar resultados indesejados em caso de má implementação em classes de implementação. Vamos olhar para isto com um exemplo simples.

public interface MyData {

    default void print(String str) {
        if (!isNull(str))
            System.out.println("MyData Print::" + str);
    }

    static boolean isNull(String str) {
        System.out.println("Interface Null Check");

        return str == null ? true : "".equals(str) ? true : false;
    }
}

Agora vamos ver um classe de implementação que está tendo método isNull () com má implementação.

public class MyDataImpl implements MyData {

    public boolean isNull(String str) {
        System.out.println("Impl Null Check");

        return str == null ? true : false;
    }

    public static void main(String args[]){
        MyDataImpl obj = new MyDataImpl();
        obj.print("");
        obj.isNull("abc");
    }
}

Note que isNull(String str) é um método de classe simples, não está sobrepondo o método de interface. Por exemplo, se adicionarmos a anotação @Override ao método isNull (), resultará em erro de compilador.

Agora, quando vamos executar a aplicação, temos que seguir a saída.

Verificação Nula Da Interface

Verificação Inválida

Se chegarmos à interface método de estática para Padrão, vamos obter a saída seguinte.

Verificação Inválida

MyData Print::

Verificação Inválida

O método estático da interface Java é visível apenas para os métodos de interface, se removermos o método isNull () da classe MyDataImpl, não seremos capazes de usá-lo para o objeto MyDataImpl. No entanto, como outros métodos estáticos, podemos usar métodos estáticos de interface usando o nome da classe. Por exemplo, uma declaração válida be:

boolean result = MyData.isNull("abc");

Pontos importantes sobre o método estático da interface java:

1. Java interface static method is part of interface, we can'T use it for implementation class objects.
2. os métodos estáticos da interface Java são bons para fornecer métodos utilitários, por exemplo, verificação nula, ordenação de colecções, etc.
3. O método estático da interface Java ajuda-nos a fornecer segurança ao não permitir que as classes de implementação as substituam.
Não podemos definir interface. método estático para Métodos de classe de objeto, vamos obter erro de compilador como "este método estático não pode esconder o método de instância do objeto". Isto porque não é permitido em java, já que o objeto é a classe base para todas as classes e não podemos ter um método estático de nível de classe e outro método de instância com a mesma assinatura.
4. podemos usar métodos estáticos de interface java para remover classes de utilitários como coleções e mover todos os seus métodos estáticos para a interface correspondente, que seria fácil de encontrar e usar.

---

Interfaces Funcionais Java

Antes de concluir o post, gostaria de apresentar uma breve introdução às interfaces funcionais. Uma interface com exatamente um método abstrato é conhecida como Interface funcional.

Foi introduzida uma nova anotação @FunctionalInterface para marcar uma interface como Interface funcional. @FunctionalInterface a anotação é uma facilidade para evitar a adição acidental de métodos abstractos nas interfaces funcionais. É ... opcional, mas boa prática para usá-lo.

Interfaces funcionais são muito aguardadas e muito procuradas característica do Java 8 porque nos permite usar expressões lambda para instanciá-las. Um novo pacote java.util.função com um monte de interfaces funcionais são adicionados para fornecer tipos de alvo para expressões lambda e referências de método. Vamos olhar para interfaces funcionais e expressões lambda nos futuros posts.

Localização Do Recurso:

1. Java 8 Alterações da Interface-método estático, método por omissão

A tua explicação parece decente,mas pode parecer que estavas a ler tudo de um livro? :-/ O que me preocupa mais é, quão sólido foi o teu exemplo? Você se deu ao trabalho de incluir quase todas as diferenças entre o abstrato e as interfaces? Pessoalmente, sugiro esta ligação.: http://mindprod.com/jgloss/interfacevsabstract.html#TABLE

Para uma lista exaustiva de diferenças..

Espero que te ajude a ti e a todos os outros. leitores nas suas futuras entrevistas

Muitos desenvolvedores jovens cometem o erro de pensar em interfaces, classes abstratas e concretas como Pequenas variações da mesma coisa, e escolher um deles puramente por razões técnicas: preciso de herança múltipla? Preciso de algum lugar para pôr métodos comuns? Preciso de me preocupar com outra coisa que não seja uma aula de cimento? isto está errado, e escondido nestas perguntas está o principal problema: " I " . Quando escreves um código para ti, sozinho, raramente pense em outros desenvolvedores presentes ou futuros trabalhando em ou com o seu código.

As Interfaces e as classes abstractas, embora aparentemente semelhantes do ponto de vista técnico, têm significados e objectivos completamente diferentes.

Resumo

1. Uma interface define um contrato que alguma implementação irá cumprir para si .

2. Uma classe abstrata fornece um comportamento padrão que o seu a implementação pode ser reutilizada.

Estes dois pontos acima são o que procuro quando estou a entrevistar, e é um resumo compacto o suficiente. Leia mais detalhes.

Resumo alternativo

1. uma interface é para definir APIs públicas
2. Uma classe abstracta é para uso interno e para definir SPIs

Por exemplo

Dito de forma diferente: uma classe concreta faz o trabalho real, de uma forma muito específica. Por exemplo, um ArrayList usa uma área contígua de memória para armazenar uma lista de objetos em uma forma compacta, que oferece rápido acesso aleatório, iteração, e no lugar muda, mas é terrível em inserções, exclusões e, ocasionalmente, até mesmo adições; enquanto isso, um LinkedList usa duas vezes vinculada nós para armazenar uma lista de objetos, os quais, em vez disso, oferece iteração rápida, no local de alterações e de inserção/exclusão/adição, mas é terrível de acesso aleatório. Estes dois tipos de listas são otimizados para diferentes casos de uso, e na verdade, isso é o que é neste momento. Todos os desenvolvedores do Java teriam adaptado seu código para se ajustar aos detalhes de implementação: evite o acesso aleatório, adicione um cache para acelerar o acesso, ou apenas reimplement {[[0]} por conta própria, embora fosse incompatível com todos os outros códigos que realmente funcionam apenas com List. Isso seria terrível... Mas agora imagine que os Java masters realmente percebem que uma lista vinculada é terrível para a maioria dos casos de uso real, e decidiram mudar para uma lista de array para a sua única classe disponível. Isso afetaria o desempenho de todos os programas Java no mundo, e as pessoas não ficariam felizes com isso. E o principal culpado é que detalhes de implementação estavam disponíveis, e os desenvolvedores assumiram que esses detalhes são um contrato permanente que eles podem confiar. É por isso que é importante esconder detalhes de implementação, e definir apenas um contrato abstrato. Este é o propósito de uma interface: definir que tipo de entrada um método aceita, e o que o tipo de saída é esperado, sem expor todas as entranhas que tentariam programadores a ajustar o seu código para caber os detalhes internos que poderiam mudar com qualquer atualização futura. Uma classe abstrata está no meio entre interfaces e classes concretas. É suposto ajudar implementações compartilhar código comum ou chato. Por exemplo, AbstractCollection fornece implementações básicas para isEmpty baseado no tamanho é 0, contains como iterate e compare, addAll como repetido add, e assim por diante. Isto permite implementações focam nas partes cruciais que diferenciam entre eles: como realmente armazenar e recuperar dados. Outra perspectiva: APIs versus SPIs As Interfaces são de baixa coesão entre diferentes partes do Código. Eles permitem que as bibliotecas existam e evoluam sem quebrar todos os usuários da biblioteca quando algo muda internamente. Chama-se Interface de programação de aplicações , não são aulas de programação de aplicações. Em um menor scale, eles também permitem que vários desenvolvedores colaborem com sucesso em projetos de grande escala, separando diferentes módulos através de interfaces bem documentadas.

As classes Abstractas são ajudantes de alta coesão a serem usados na implementação de uma interface, assumindo algum nível de detalhes de implementação. Alternativamente, classes abstratas são usadas para definir SPIs, Interfaces de prestadores de Serviços.

A diferença entre uma API e uma SPI é subtil, mas importante: API, o foco é em quem usa ele, e para um SPI o foco é em quem implementa ele.

Adicionar métodos a uma API é fácil, todos os utilizadores da API ainda irão compilar. Adicionar métodos a um SPI é difícil, uma vez que cada prestador de serviços (implementação concreta) terá de implementar os novos métodos. Se as interfaces são usadas para definir um SPI, um provedor terá que liberar uma nova versão sempre que o contrato SPI muda. Se forem utilizadas classes abstractas em vez disso, as novas os métodos podem ser definidos em termos de métodos abstratos existentes, ou como stubs throw not implemented exception vazios, o que permitirá pelo menos uma versão mais antiga de uma implementação de Serviço para ainda compilar e executar.

Uma nota sobre Java 8 e métodos predefinidos

Embora o Java 8 tenha introduzido métodos padrão para interfaces, o que torna a linha entre interfaces e classes abstratas ainda mais borrada, isso não foi para que as implementações possam reutilizar o código, mas para tornar mais fácil a mudança de interfaces que servem tanto como uma API e como uma SPI (ou são usados erroneamente para definir SPIs em vez de classes abstratas).

"conhecimento do livro"

Os detalhes técnicos fornecidos no OP de resposta são considerados "livro do conhecimento", porque esta é geralmente a abordagem utilizada na escola e na maioria dos livros de tecnologia sobre a linguagem: que uma coisa é, não como para usá-lo na prática, especialmente em aplicações de larga escala.

Eis uma analogia: Suponha que a pergunta foi:

O que é melhor para alugar para o baile de finalistas, um carro ou um quarto de hotel?

A resposta técnica soa como:

Bem, num carro podes fazê-lo mais cedo, mas num quarto de hotel podes fazê-lo mais confortavelmente. Por outro lado, o quarto de hotel está em apenas um lugar, enquanto no carro você pode fazê-lo em mais lugares, como, digamos que você pode ir para o vista point para uma vista agradável, ou em um drive-in teatro, ou muitos outros lugares, ou até mesmo em mais de um lugar. Além disso, o quarto do hotel tem um chuveiro.

Isso é tudo verdade, mas falha completamente os pontos que são duas coisas completamente diferentes, e ambos podem ser usados ao mesmo tempo para propósitos diferentes, e o aspecto "fazê-lo" não é a coisa mais importante sobre qualquer uma das duas opções. A resposta carece de perspectiva, mostra uma forma imatura de pensar, apresentando corretamente "fatos"verdadeiros.

Uma interface é um "contrato" em que a classe que executa o contrato promete implementar os métodos. Um exemplo onde eu tive que escrever uma interface em vez de uma classe foi quando eu estava atualizando um jogo de 2D para 3D. eu tive que criar uma interface para compartilhar classes entre o 2D e a versão 3D do jogo.

package adventure;
import java.awt.*;
public interface Playable {
    public void playSound(String s);
    public Image loadPicture(String s);    
}

Então eu posso implementar os métodos baseados no ambiente, enquanto ainda sendo capaz de chamar esses métodos a partir de um objeto que não sabe qual versão de o jogo que está a carregar.

public class Adventure extends JFrame implements Playable

public class Dungeon3D extends SimpleApplication implements Playable

public class Main extends SimpleApplication implements AnimEventListener, ActionListener, Playable

Normalmente, no gameworld, o mundo pode ser uma classe abstrata que executa métodos no jogo.

public abstract class World...

    public Playable owner;

    public Playable getOwner() {
        return owner;
    }

    public void setOwner(Playable owner) {
        this.owner = owner;
    }

As classes abstratas devem ser herdadas de, E quando uma classe herda de outra significa que há uma forte relação entre as duas classes. Com uma interface por outro lado, a relação entre a interface em si e a classe que implementa a interface não é necessariamente forte. Assim, podemos resumir este primeiro ponto dizendo que uma classe abstrata seria mais apropriada quando há uma forte relação entre a classe abstrata e as classes. isso derivará disso. Mais uma vez, isto é porque uma classe abstrata está muito intimamente ligada à herança, o que implica uma relação forte. Mas, com as interfaces não precisa haver uma forte relação entre a interface e as classes que implementam a interface. A interface Java pode estender a interface múltipla também a classe Java pode implementar várias interfaces, o que significa que a interface pode fornecer mais suporte de polimorfismo do que a classe abstrata . Ao estender a classe abstrata, uma classe só pode participar em uma hierarquia de tipo, mas usando interface pode ser parte de várias hierarquias de tipo.

A fim de implementar a interface em Java, até que a sua classe seja abstrata, você precisa fornecer a implementação de todos os métodos, o que é muito doloroso. Por outro lado, a classe abstrata pode ajudá-lo neste caso, fornecendo a implementação padrão.

Que tal pensar da seguinte maneira:

• uma relação entre uma classe e uma classe abstrata é do tipo "is-a"
• uma relação entre uma classe e uma interface é do tipo "has-a"

Então, quando se tem um mamífero de classe abstrata, uma subclasse humana, e uma interface de condução, então você pode dizer {[[2]}

Cada humano é um mamífero. Cada humano tem uma condução (comportamento)

A minha sugestão é que a frase do conhecimento do livro indica que ele queria ouvir a diferença semântica entre ambos (como outros aqui já sugeriram).

As classes abstratas não são abstracção pura bcz a sua colecção de métodos concretos(métodos implementados), bem como métodos não implementados. Mas Interfaces são pura abstração bcz existem apenas métodos não implementados Não métodos concretos.

Porquê aulas Abstractas?

1. Se o utilizador quiser escrever funcionalidade comum para todos os objectos.
2. classes abstratas são a melhor escolha para reimplementação no futuro que para adicionar mais funcionalidade sem afetar o fim usuario.

Porquê Interfaces?

1. Se o utilizador quiser escrever diferentes funcionalidades que seriam diferentes nos objectos.
2. as Interfaces são a melhor opção se não for necessário alterar os requisitos após a publicação da interface.

A principal diferença que eu observei foi que a classe abstrata nos fornece algum comportamento comum já implementado e as subclasses só precisam implementar funcionalidade específica correspondente a elas. onde, como para uma interface só especificará quais tarefas precisam ser feitas e nenhuma implementação será dada pela interface. Posso dizer que especifica o contrato entre si e classes implementadas.

Uma interfaceé como um conjunto de genes que estão publicamente documentados para ter algum tipo de efeito: um teste de ADN irá dizer - me se os tenho-e se o fizer, posso publicamente fazer saber que sou um "portador" e parte do meu comportamento ou estado irá conformar-se com eles. (Mas é claro, eu posso ter muitos outros genes que fornecem traços fora deste escopo.)

An abstract class is like the dead ancestor of a single-sex species (*): She can't be brought to life mas um descendente vivo (isto é, não-Abstrato) herda todos os seus genes.

Para esticar esta metáfora, digamos que todos os membros da espécie vivem até à mesma idade. Isto significa que todos os ancestrais de um ancestral morto também devem estar mortos-e da mesma forma, todos os descendentes de um ancestral vivo devem estar vivos.

Eu dou entrevistas para o trabalho e também olharia desfavoravelmente para a sua resposta (desculpe, mas sou muito honesto). Parece que leu sobre a diferença e reviu uma resposta, mas talvez nunca a tenha usado na prática.

Uma boa explicação para o porquê de usarem cada um pode ser muito melhor do que ter uma explicação precisa da diferença. Os empregadores ultimatley querem programadores para fazer coisas que não os conhecem, o que pode ser difícil de demonstrar em uma entrevista. A resposta gave seria bom se se candidatasse a um trabalho técnico ou baseado em documentação, mas não a um papel de desenvolvedores.

Boa sorte com as entrevistas no futuro.

Também a minha resposta a esta pergunta é mais sobre técnica de entrevista do que o material técnico que forneceu. Talvez considere ler sobre isso. https://workplace.stackexchange.com pode ser um lugar excelente para este tipo de coisas.

Uma interface é puramente abstracta. não temos nenhum código de implementação na interface.

A classe Abstract contém métodos e a sua aplicação.

Carregue aqui para ver o tutorial sobre interfaces e classes abstractas

A principal diferença que eu observei foi que a classe abstrata nos fornece algum comportamento comum já implementado e as subclasses só precisam implementar funcionalidade específica correspondente a elas. onde, como para uma interface só especificará quais tarefas precisam ser feitas e nenhuma implementação será dada pela interface. Posso dizer que especifica o contrato entre si e classes implementadas.

Até eu já enfrentei a mesma pergunta em várias entrevistas e acredita que torna o teu tempo miserável convencer o entrevistador. Se eu inerente todas as respostas de cima então eu preciso adicionar mais um ponto chave para torná-lo mais convincente e utilizando OO no seu melhor

No caso de não estar a planear qualquer modificação nas regras , para que a subclasse seja seguida, por um longo futuro, vá para a interface, como não será capaz de modificar nela e se o fizer, terá de para ir para as mudanças em todas as outras classes, enquanto, se você pensar, você quer reutilizar a funcionalidade, definir algumas regras e também torná-lo aberto para modificação, vá para a classe abstrata.

Pense desta forma, você tinha usado um serviço consumível ou tinha fornecido algum código para o mundo e você tem a chance de modificar algo, suponha uma verificação de segurança E se estou a ser um consumidor do código e uma manhã depois de uma actualização, encontro todas as marcas de leitura no meu Eclipse, a aplicação está em baixo. Assim, para evitar tais pesadelos, use o abstrato sobre Interfaces Acho que isto pode convencer até certo ponto o entrevistador...Boas Entrevistas Pela Frente.

Você escolhe a Interface em Java para evitar o problema do diamante em herança múltipla .

Se você quer que todos os seus métodos sejam implementados pelo seu cliente, você vai para interface. Significa que desenhas toda a aplicação em abstract.

Você escolhe a classe abstrata se já sabe o que é em comum. Por exemplo, tome uma classe abstrata Car. A um nível mais alto você implementa os métodos comuns do carro como calculateRPM(). É um método comum e você deixa o cliente implementar o seu próprio comportamento como
calculateMaxSpeed() etc. Provavelmente você teria explicado dando poucos exemplos em tempo real que você encontrou em seu trabalho diário.

Quando estou tentando compartilhar o comportamento entre duas classes intimamente relacionadas, eu crio uma classe abstrata que mantém o comportamento comum e serve como um pai para ambas as classes.

Quando estou tentando definir um tipo, uma lista de métodos que um usuário de meu objeto pode chamar de forma confiável, então eu crio uma interface.

Por exemplo, eu nunca criaria uma classe abstrata com 1 subclasse concreta porque as classes abstratas são sobre o comportamento de partilha. Mas talvez o faça. muito bem criar uma interface com apenas uma implementação. O usuário do meu código não saberá que existe apenas uma implementação. Na verdade, em um lançamento futuro pode haver várias implementações, todas as quais são subclasses de alguma nova classe abstrata que nem sequer existia quando eu criei a interface.

([1]) isso pode ter parecido um pouco demasiado reservado também (embora eu nunca o tenha visto colocar dessa forma em qualquer lugar que eu me lembre). Se o entrevistador (ou o OP) realmente queria mais do meu pessoal a experiência a este respeito, eu estaria pronto com anedotas de uma interface evoluiu por necessidade e visa-versa.

Mais uma coisa. O Java 8 permite-lhe agora colocar o código por omissão numa interface, borrando ainda mais a linha entre interfaces e classes abstractas. Mas pelo que eu vi, esse recurso é usado até mesmo pelos fabricantes das bibliotecas Java core. Esse recurso foi adicionado, e com razão, para tornar possível estender uma interface sem criar binário incompatibilidade. Mas se você está fazendo um tipo novo ao definir uma interface, então a interface deve ser apenas uma interface. Se você quiser também fornecer código comum, então por todos os meios faça uma classe auxiliar (abstrato ou concreto). Não esteja atrapalhando sua interface desde o início com a funcionalidade que você pode querer mudar.

Pelo que eu entendo, uma Interface, que é composta de variáveis finais e métodos sem implementações, é implementada por uma classe para obter um grupo de métodos ou métodos que estão relacionados uns com os outros. Por outro lado, uma classe abstrata, que pode conter variáveis não-finais e métodos com implementações, é geralmente usada como um guia ou como uma superclasse da qual todas as classes relacionadas ou similares herdam. Em outras palavras, uma classe abstrata contém todos os métodos / variáveis que são compartilhados por todas as suas subclasses.

Na classe abstracta, você pode escrever a implementação predefinida dos métodos! Mas na Interface você não pode. Basicamente, na interface existem métodos virtuais puros que têm de ser implementados pela classe que implementa a interface.

Agora as pessoas estão com fome, tem toda a razão, mas a maioria dos entrevistadores está de acordo com o seu pedido actual e quer uma abordagem prática.

Depois de terminar a sua resposta, deve seguir o exemplo:

Resumo:

Por exemplo, temos uma função salarial que tem um parametar comum a todos os empregados. então podemos ter uma classe abstrata chamada CTC com corpo de método partialy definido e ele vai se estender por todo o tipo de empregado e ser redimido de acordo com os seus lucros extra. Pela funcionalidade comum.

public abstract class CTC {

    public int salary(int hra, int da, int extra)
    {
        int total;
        total = hra+da+extra;
        //incentive for specific performing employee
        //total = hra+da+extra+incentive;
        return total;
    }
}

class Manger extends CTC
{
}


class CEO extends CTC
{
}

class Developer extends CTC
{   
}

Interface

A Interface em java permite ter a funcionalidade interfcae sem estender essa funcionalidade e você tem que ser claro com a implementação da assinatura de funcionalidade que você quer introduzir em sua aplicação. vai forçá-lo a ter certeza. Para diferentes funcionalidades. interface pública EmployeType {

    public String typeOfEmployee();
}

class ContarctOne implements EmployeType
{

    @Override
    public String typeOfEmployee() {
        return "contract";
    }

}

class PermanentOne implements EmployeType
{

    @Override
    public String typeOfEmployee() {
        return "permanent";
    }

}

Podes ter tanta actividade forçada com classe abstrata também por methgos definido como um abstrato, agora uma classe tha estende classe abstrata abstrata Remin abstrato Um até que Ele sobrepõe essa função abstrata.

Sim, as tuas respostas estavam tecnicamente correctas, mas onde erraste não foi mostrar-lhes que entendes as vantagens e desvantagens de escolheres uma em vez da outra. Além disso, eles provavelmente estavam preocupados/assustados com a compatibilidade de sua base de código com atualizações no futuro. Este tipo de resposta pode ter ajudado (além do que você disse):

" Escolher uma classe abstrata em vez de uma classe de Interface depende do que nós projectar o futuro do Código ser.

As classes Abstractas permitem uma melhor compatibilidade para a frente porque pode continuar a adicionar o comportamento a uma classe abstracta bem no futuro sem quebrar o seu código existente --> isto não é possível com um Classe De Interface.

Por outro lado, As Classes de Interface são mais flexíveis do que Abstractas Classe. Isto porque eles podem implementar interfaces múltiplas . O o problema é que o Java não tem várias heranças, por isso, usando o abstract as aulas não deixar-te usar qualquer outra estrutura de Hierarquia de classes...

Então, no final, uma boa regra geral é: preferir usar a Interface Classes quando não existem implementações existentes/predefinidas no seu codigo. E, use Classes abstratas para preservar a compatibilidade se você saiba que você estará atualizando sua classe no futuro."

Boa sorte para a próxima entrevista!

Vou tentar responder usando um cenário prático para mostrar a distinção entre os dois.

As Interfaces vêm com carga zero, ou seja, nenhum Estado tem de ser mantido e, portanto, é melhor escolher apenas associar um contrato (capacidade) com uma classe.

Por exemplo, digamos que eu tenho uma classe de tarefa que executa alguma ação, agora para executar uma tarefa em um tópico separado eu realmente não preciso estender a classe de Thread bastante melhor escolha é fazer tarefa implementar interface Runnable (i.e. implemente seu método run () e então passe o objeto desta classe de tarefa para uma instância Thread e chame seu método start ().

E se Runnable fosse uma aula abstracta?

Bem, tecnicamente isso foi possível, mas design Sábio que teria sido uma má escolha sendo:

• Runnable não tem estado associado a ele e nem "oferece" qualquer implementação por omissão para o método run ()
A tarefa teria que estendê-la assim. não podia estender nenhuma outra classe.
• a tarefa não tem nada a oferecer como especialização para a classe executável, tudo o que precisa é substituir o método run ()

Em outras palavras, A classe de tarefa precisava de uma capacidade para ser executado em um thread que ele conseguiu implementando versos de interface Runnable estendendo a classe de Thread que o tornaria um thread.

Basta colocar a interface dos EUA para definir uma capacidade (Contrato), enquanto usa um classe abstracta para definir o esqueleto (comum / parcial) execução ele.

Disclaimer: silly example follows, try not to judge : - P

interface Forgiver {
    void forgive();
}

abstract class GodLike implements Forgiver {
    abstract void forget();
    final void forgive() {
        forget();
    }
}

Agora foi-vos dada a escolha de ser como Deus, mas podeis escolher ser apenas Perdoadores (isto é, não como Deus) e fazer:

class HumanLike implements Forgiver {
    void forgive() {
       // forgive but remember    
    }
}

Ou podes escolher Ser Divino e fazer:

class AngelLike extends GodLike {
    void forget() {
       // forget to forgive     
    }
}

P. S. with java 8 interface can also have static as well default (overridable implementation) methods and thus difference B / w interface and abstract class is even mais reduzido.

Quase tudo parece estar coberto aqui.. Adicionando apenas mais um ponto sobre a aplicação prática da classe abstract:

abstract a palavra-chave também é usada apenas para evitar que uma classe seja instanciada. Se você tem uma classe de concreto que você não quer ser instanciado-Faça-o abstract.

A tua resposta está bem, mas acho que ele estava à procura deste tipo de resposta.

Classe abstracta

• a classe abstracta pode ter métodos abstractos e não abstractos.
A classe abstracta não suporta herança múltipla.
• a classe abstrata pode ter variáveis finais, não-finais, estáticas e não-estáticas.
• A classe Abstract pode fornecer a implementação da interface.

Interface

• a Interface pode ter predefinição, métodos estáticos e abstratos.
• a Interface suporta herança múltipla.
• a Interface tem apenas variáveis estáticas e finais.
• a Interface não pode fornecer a implementação da classe abstrata.

Pelo que entendo e como me aproximo,

A Interface é como uma especificação / contrato, qualquer classe que implemente uma classe de interface tem de implementar todos os métodos definidos na classe abstract (excepto os métodos predefinidos (introduzidos em java 8)

Considerando que eu defino um abstrato de classe Quando eu sei a implementação necessária para alguns métodos da classe e alguns métodos eu ainda não sei o que será a implementação(podemos saber a assinatura da função, mas não a implementacao). Eu faço isso para que mais tarde, na parte do desenvolvimento, quando eu sei como esses métodos devem ser implementados, eu posso simplesmente estender esta classe abstrata e implementar esses métodos.

Nota: Não pode ter corpo de funções nos métodos de interface, a menos que o método seja estático ou por omissão.

Acho que o entrevistador estava a tentar chegar à diferença entre interface e implementação.

A interface - não uma interface Java, mas "interface" em termos mais gerais - para um módulo de código é, basicamente, o contrato feito com o código cliente que usa a interface.

A implementação de um módulo de código é o código interno que faz o módulo funcionar. Muitas vezes você pode implementar uma interface particular em mais de uma maneira diferente, e até mesmo alterar a implementação sem que o código do cliente esteja ciente da mudança.

Uma interface Java só deve ser usada como uma interface no sentido genérico acima, para definir como a classe se comporta em benefício do Código Cliente usando a classe, sem especificar qualquer implementação. Assim, uma interface inclui assinaturas de métodos-os nomes, tipos de retorno e listas de argumentos-para métodos que se espera serem chamados pelo código cliente, e em princípio deve ter abundância de Javadoc para cada método descrevendo o que esse método faz. A razão mais convincente para usar uma interface é se você planeja ter várias implementações diferentes da interface, talvez selecionando uma implementação dependendo da configuração de implantação.

Uma classe abstrata Java, em contraste, fornece uma implementação parcial da classe, em vez de ter um propósito primário de especificar uma interface. Ele deve ser usado quando várias classes compartilham código, mas quando as subclasses também são esperados para fornecer parte da implementação. Isto permite que o código compartilhado apareça em apenas um lugar - a classe abstrata - ao mesmo tempo em que deixa claro que partes da implementação não estão presentes na classe abstrata e são esperados para ser fornecido por subclasses.

A sua resposta está certa, mas o entrevistador precisa que se diferencie de acordo com a perspectiva de engenharia de software e não de acordo com os detalhes de Java.

Palavras Simples:

Uma Interface é como a interface de uma loja qualquer coisa que é mostrado nela deve estar lá na loja, então qualquer método na Interface deve estar lá implementado na classe de concreto. Agora, e se algumas classes compartilham alguns métodos exatos e varia em outros. Suponha que a Interface é sobre uma loja que contém duas coisas e suponha que temos duas lojas ambos contêm equipamentos esportivos, mas um tem roupas extra e o outro tem sapatos extra. Então o que você faz é fazer uma aula abstrata para o esporte que implementa o método esportivo e deixa o outro método Não implementado. Classe abstrata aqui significa que esta Loja não existe em si mesma, mas é a base para outras classes/lojas. Desta forma você está organizando o código, evitando erros de replicação do Código, unificando o código, e garantindo a reutilização por outra aula qualquer.