Instruções de uso do Java Interface - são getters e setters em um mau interface?

Question

O que as pessoas pensam dos melhores diretrizes para usar em uma interface? O que deve e não deve entrar em uma interface?

pessoas

que eu ouvi dizer que, como regra geral, uma interface deve apenas definir o comportamento e não do Estado. Isso significa que uma interface não deve conter getters e setters?

A minha opinião: Talvez não para setters, mas às vezes eu acho que getters são válidos para ser colocado em uma interface. Este é apenas para fazer cumprir as classes de implementação para implementar essas getters e assim indicar que os clientes são capazes de chamar os getters para verificar alguma coisa, por exemplo.

Answer 1

Eu acho que existem dois tipos de interfaces declaradas em geral:

1. uma descrição serviço . Isso pode ser algo como CalculationService. Eu não acho que os métodos getX deve ser neste tipo de interface, e certamente não setX. Eles claramente implica detalhe de implementação, o que não é o trabalho deste tipo de interface.
2. um modelo dados - existe unicamente para abstrair a implementação de objetos de dados no sistema. Estes podem ser utilizados para auxiliar nos testes ou apenas porque algumas pessoas tão antiga como me lembro dos dias em que (por exemplo) usando um framework de persistência amarrou você para baixo para ter um superclasss particular (ou seja, você iria escolher para implementar uma interface no caso de você comutada sua camada de persistência). Eu acho que ter métodos JavaBean neste tipo de interface é inteiramente razoável.

Nota: as classes de coleções provavelmente caber em digitar # 2

Answer 2

Eu não vejo por que uma interface não pode definir getters e setters. Por exemplo, List.size() é efectivamente um absorvente. A interface deve definir o comportamento ao invés do aplicação - embora ele não pode dizer como você vai alça do estado, mas pode insistir que você pode obtê-lo e conjunto -lo.

interfaces de coleção são todos sobre o estado, por exemplo - mas diferentes coleções pode armazenar esse estado de maneiras radicalmente diferentes

.

EDIT: Os comentários sugerem que getters e setters implica um campo simples é usado para fazer backup de armazenamento. I discordar veementemente com esta implicação. Para minha mente há uma implicação que é "razoavelmente barato" para obter / definir o valor, mas não que ele é armazenado como um campo com uma implementação trivial.

---

EDIT: Como observado nos comentários, este é explicitada na JavaBeans especificação seção 7.1:

Assim, mesmo quando um tipos roteirista em algo como b.Label = foo ainda há uma chamada de método para a alvo de objeto para definir a propriedade, e o objecto alvo tem completo controle programático.

Assim propriedades não precisa apenas ser simples campos de dados, eles podem realmente ser valores calculados. Atualizações podem ter vários efeitos secundários programáticos. Para exemplo, alterar fundo de um bean propriedade de cor também pode fazer com que o feijão a ser repintado com o novo cor ".

---

Se a suposta implicação foram verdade, nós poderia muito bem expor propriedades como campos diretamente. Felizmente essa implicação não espera: getters e setters são perfeitamente dentro de seus direitos para as coisas de computação

.

Por exemplo, considere um componente com

getWidth()
getHeight()
getSize()

Você acredita que há uma implicação de que existem três variáveis ??lá? Não seria razoável que quer ter:

private int width;
private int height;

public int getWidth() {
    return width;
}

public int getHeight() {
    return height;
}

public Size getSize() {
    return new Size(width, height); // Assuming an immutable Size type
}

Ou (de preferência IMO):

private Size size;

public int getWidth() {
    return size.getWidth();
}

public int getHeight() {
    return size.getHeight();
}

public Size getSize() {
    return size;
}

Aqui, quer a propriedade tamanho ou a altura / largura propriedades são apenas para conveniência - mas eu não vejo isso que os torna inválido de qualquer maneira

.

Answer 3

Não há nada inerentemente mau sobre getters / setters. No entanto:

1. I tendem a fazer meus objetos imutáveis ??(em primeira instância) em relação aos campos que contêm. Por quê ? Eu instanciar a maioria das coisas durante a fase de construção. Se eu quiser mudar alguma coisa mais tarde, então eu relaxar essas restrições. Então meus interfaces de tenderá a conter getters, mas não formadores (há outros benefícios - particularmente enfiar)
.
2. Eu quero que meus objetos para fazer coisas para me , e não o contrário. Assim, quando um dos meus objetos adquire uma série de getters, eu começo a perguntar se esse objeto deve ter mais funcionalidade em que, em vez de expor todos os seus dados para outra coisa para trabalhar. Consulte esta resposta para obter mais detalhes.

Estas são todas as diretrizes, nota.

Answer 4

Eu não acho que um feijão deve ter uma interface em cima dela, em geral. A javabean é uma interface no sentido mais geral. Uma interface especifica o contrato externo de algo mais complexo. contrato externa de um javabean e sua representação interna são idênticos.

Eu não diria que você não deve ter getters em uma interface, no entanto. Faz todo o sentido ter uma interface ReadableDataThingie que é implementado por DataThingieBean.

Answer 5

pessoas

que eu ouvi dizer que, como um regra geral, uma interface única deve definem o comportamento e estado não. Faz Isso significa que uma interface não deve conter getters e setters?

Para começar, pelo menos com Java e excluindo declarações de exceção, você não pode definir o comportamento completo sem estado. Em Java, as interfaces não definem o comportamento. Eles não podem. O que eles definem são tipos; promessas de implementar um conjunto de assinaturas característica possivelmente com algumas pós-condições wrt exceções. Mas é isso. Comportamento e estado são definidas por classes que implementam essas interfaces.

Em segundo lugar, se getters e setters são definidos em uma interface, eles realmente não definir o comportamento completo (outro que é para leitura e um é para gravação wrt uma propriedade.) Você pode ter um comportamento complexo por trás setters e getters, mas eles só podem ser implementados nas classes reais. Não há nada na linguagem Java que pode permitir-nos definir livremente o comportamento nas interfaces exceto para a mais restritiva dos casos.

Com isso em consideração, não há nada de errado - sintática e semanticamente -. Com ter setters e getters nas interfaces

Se o seu pedido for bem modelados e o problema requer que você tenha uma interface que define setters e getters, por que não. Por exemplo, dê uma olhada na interface ServletResponse.

Agora, se olharmos para getters e setters a partir do ponto de vista da implementação de classes em conformidade com as especificações JavaBeans, então você não precisa definir as interfaces para eles.

Mas se você tem coisas que exigem setters e getters, como uma força de feijão, e que também é necessário para ser conectado na compilação do tipo (não em tempo de execução como uma força de feijão), e para o qual pode existir múltiplas implementações , então sim, isso exigiria uma interface que define getters e setters.

Hope isso ajuda.

Answer 6

Esta questão coloca todo o Getter / Setters são maus tema que é abordado várias vezes neste site e em outros lugares.

I tendem a favorecer não ter acessores na interface, mas para adicionar colaboradores usando argumentos do construtor para a implementação.

Answer 7

O facto da implementação direta de alguma coisa é como um getter não deve impedi-lo de estar em uma interface se ele precisa ser.

Answer 8

Para ler mais:. API Prático projeto Confissões de um Arquiteto Java Framework (Jaroslav Tulach, 2008, Apress)

Answer 9

Eu usei esse tipo de interfaces, por exemplo, tivemos aulas com campos beginDate, endDate. Esses campos eram em muitas classes e eu tive um caso de uso que eu preciso para obter essas datas para diferentes objetos, então eu extraído interface e estava muito feliz:)

Answer 10

Basicamente, se a resposta à pergunta "Do que eu preciso saber o valor de [Estado, a propriedade, whateverThignAMaGit], a fim de trabalhar com uma instância dele?" então sim ... os acessores pertencem à interface.

List.size () de John acima é um exemplo perfeito de um getter que precisa ser definido em uma interface

Answer 11

Getters são usados ??para consultar o estado de um objeto - o que você pode realmente evitar ao projetar sua interface. Leia http://www.pragprog.com/articles/tell-dont-ask