Como você acessar as propriedades de objetos de dentro de um método de objeto?

votos
81

Qual é o purista ou maneira correta para acessar propriedades de um objeto de dentro de um método de objeto que não é um método getter / setter?

Eu sei que do lado de fora do objeto que você deve usar um getter / setter, mas de dentro se você acabou de fazer:

Java:

String property = this.property;

PHP:

$property = $this->property;

ou que você faria:

Java:

String property = this.getProperty();

PHP:

$property = $this->getProperty();

Perdoe-me se o meu Java é um pouco fora, ele tem sido um ano desde que eu programado em Java ...

EDITAR:

Parece que as pessoas estão supondo que eu estou falando sobre variáveis ​​/ únicas propriedades privadas ou protegidas. Quando eu aprendi OO eu fui ensinado a usar getters / setters para cada propriedade, mesmo se fosse público (e, na verdade, me disseram para nunca fazer qualquer variável pública / propriedade). Então, eu posso ser o arranque de uma falsa suposição de o ir buscar. Parece que as pessoas responder a esta pergunta são talvez dizer que você deve ter propriedades públicas e que aqueles não precisam de getters e setters, que vai contra o que me ensinaram, e que eu estava falando, embora talvez que precisa ser discutido como bem. Isso é provavelmente um bom tema para uma pergunta diferente embora ...

Publicado 01/08/2008 em 17:10
fonte usuário
Em outras línguas...                            


18 respostas

votos
58

Isto tem potencial guerra religiosa, mas parece-me que se você estiver usando um getter / setter, você deve usá-lo internamente, bem como - usando tanto vai levar a problemas de manutenção na estrada (por exemplo, alguém adiciona código para um setter que precisa para executar cada vez que a propriedade é definida, ea propriedade está sendo definida internamente w / o que setter sendo chamado).

Respondeu 01/08/2008 em 17:13
fonte usuário

votos
41

Pessoalmente, eu sinto que é importante para manter a coerência. Se você tem getters e setters, usá-los. A única vez que eu acessar um campo diretamente é quando o assessor tem um monte de sobrecarga. Ele pode se sentir como se estivesse inchaço seu código desnecessariamente, mas certamente pode salvar um monte de dor de cabeça no futuro. O exemplo clássico:

Mais tarde, você pode querer mudar a maneira que trabalhos de campo. Talvez ele deve ser calculado on-the-fly ou talvez você gostaria de usar um tipo diferente para o armazenamento de backup. Se você estiver acessando propriedades diretamente, uma mudança como essa pode quebrar uma enorme quantidade de código em um foop swell.

Respondeu 01/08/2008 em 19:23
fonte usuário

votos
25

Estou bastante surpreso com o quão unânime o sentimento é que getterse setters são muito bem e bom. Eu sugiro que o artigo incendiário por Allen Holub " getters e setters são maus ". Concedido, o título é para chocar, mas o autor faz pontos válidos.

Essencialmente, se você tem getterse setterspara cada campo particular, você está fazendo esses campos tão bom quanto público. Você ficaria muito duramente pressionado para alterar o tipo de um campo privado, sem efeitos em cascata para cada classe que chama que getter.

Além disso, de um ponto estritamente OO de vista, os objetos devem estar respondendo a mensagens (métodos) que correspondem a sua (espero) única responsabilidade. A grande maioria dos getterse settersnão fazem sentido para os seus objetos constituintes; Pen.dispenseInkOnto(Surface)faz mais sentido para mim do que Pen.getColor().

Getters e setters também incentivar os usuários da classe para pedir o objeto para alguns dados, executar um cálculo, e em seguida, definir algum outro valor no objeto, mais conhecido como programação procedural. Você estaria melhor servido para simplesmente dizer o objeto para fazer o que você estava indo para, em primeiro lugar; também conhecida como a informação especializada idioma.

Getters e setters, no entanto, são males necessários no limite de camadas - UI, persistência, e assim por diante. Restringiu o acesso ao internas de uma classe, como amigo de palavras-chave do C ++, protegido pacote de acesso de Java, acesso interno do .NET, eo Padrão amigo classe pode ajudar a reduzir a visibilidade getterse setters somente para aqueles que deles necessitam.

Respondeu 19/09/2008 em 01:13
fonte usuário

votos
18

Depende de como a propriedade é usada. Por exemplo, digamos que você tem um objeto de estudante que tem uma propriedade de nome. Você pode usar o seu método Get para puxar o nome do banco de dados, se não já foi recuperado. Desta forma, você está reduzindo chamadas desnecessárias para o banco de dados.

Agora vamos dizer que você tem um contador inteiro privado em seu objeto que conta o número de vezes que o nome foi chamado. Você pode querer não usar o método Get de dentro do objeto porque ele iria produzir uma contagem inválido.

Respondeu 01/08/2008 em 17:19
fonte usuário

votos
13

PHP oferece uma infinidade de maneiras de lidar com isso, incluindo métodos mágicos __gete __set, mas eu prefiro getters explícitas e setters. Aqui está o porquê:

  1. Validação podem ser colocados em incubadoras e getters (para esse efeito)
  2. Intellisense trabalha com métodos explícitos
  3. Nenhuma pergunta se uma propriedade é somente leitura, somente escrita ou leitura e escrita
  4. Recuperando propriedades virtuais (ou seja, os valores calculados) é a mesma de propriedades regulares
  5. Você pode facilmente configurar uma propriedade do objeto que nunca é realmente definido em qualquer lugar, que depois vai em situação irregular
Respondeu 24/09/2008 em 18:24
fonte usuário

votos
12

Estou apenas ir ao mar aqui?

Possivelmente ;)

Outra abordagem seria utilizar um método privado / protegido para realmente fazer a obtenção de (caching / db / etc), e um invólucro pública para que incrementa a contagem:

PHP:

public function getName() {
    $this->incrementNameCalled();
    return $this->_getName();
}

protected function _getName() {
    return $this->name;
}

e, em seguida, de dentro do próprio objeto:

PHP:

$name = $this->_getName();

Desta forma, você ainda pode usar esse primeiro argumento para outra coisa (como o envio de uma bandeira para se deve ou não utilizados dados em cache aqui talvez).

Respondeu 01/08/2008 em 17:43
fonte usuário

votos
11

Eu deve estar faltando o ponto aqui, por que você iria usar um getter dentro de um objeto para acessar uma propriedade do objeto?

Levando isso a sua conclusão, o getter deve chamar um getter, que deve chamar um getter.

Então eu diria que dentro de um método de acesso objeto um imóvel directamente, especialmente vendo como chamar outro método no objeto (que só vai acessar a propriedade diretamente de qualquer maneira, em seguida, devolvê-lo) é apenas um exercício inútil, desperdício (ou ter eu não entendi a pergunta ).

Respondeu 04/06/2011 em 16:42
fonte usuário

votos
7

eu diria que o seu melhor para usar os métodos de acesso, mesmo dentro do objeto. Aqui estão os pontos que vêm à minha mente imediatamente:

1) Deve ser feito no interesse de manter a consistência com acessos feitos fora do objecto.

2) Em alguns casos, estes métodos de acesso poderia estar fazendo mais do que apenas acessando o campo; eles poderiam estar fazendo algum processamento adicional (sua rara embora). Se este for o caso, acessando o campo diretamente você falta para fora que o processamento adicional e seu programa poderia dar errado se este processamento é sempre a ser feito durante esses acessos

Respondeu 20/01/2010 em 09:32
fonte usuário

votos
7

A maneira purista OO é evitar tanto e seguir a Lei de Demeter , usando o Diga não pedem a abordagem.

Em vez de começar o valor da propriedade do objeto, o que força os casais a duas classes, use o objeto como um parâmetro por exemplo,

  doSomethingWithProperty() {
     doSomethingWith( this.property ) ;
  }

Onde a propriedade era um tipo nativo, por exemplo, int, use um método de acesso, o nome de domínio do problema não o domínio de programação.

  doSomethingWithProperty( this.daysPerWeek() ) ;

Estes irão permitir-lhe manter encapsulamento e nenhum pós-condições ou invariantes dependentes. Você também pode usar o método setter para manter quaisquer pré-condições ou invariantes dependentes, no entanto, não cair na armadilha de nomeá-los setters, voltar ao Princípio Hollywood para nomear ao usar o idioma.

Respondeu 24/09/2008 em 18:04
fonte usuário

votos
7

Se por "purista" quer dizer "mais encapsulamento", então eu normalmente declarar todos os meus campos como privado e, em seguida, usar this.field de dentro da própria classe, mas todas as outras classes, incluindo subclasses, estado da instância de acesso usando os getters.

Respondeu 22/08/2008 em 12:15
fonte usuário

votos
6

Depende. É mais uma questão de estilo do que qualquer outra coisa, e não há nenhuma regra dura.

Respondeu 01/10/2008 em 11:51
fonte usuário

votos
6

Se eu não vou editar a propriedade Vou usar um get_property()método público a menos que seja uma ocasião especial, como um objeto MySQLi dentro de outro objeto que no caso eu vou apenas pública a propriedade e se referem a ele como $obj->object_property.

Dentro do objeto é sempre $ this-> propriedade para mim.

Respondeu 22/08/2008 em 12:34
fonte usuário

votos
6

campos particulares com propriedades públicas ou protegidas. Acesso aos valores deve percorrer as propriedades e ser copiado para uma variável local se eles serão utilizados mais de uma vez em um método. Se e somente se você tem o resto de sua aplicação de modo totalmente mexido, balançado para fora, e de outra forma otimizada para onde acessando valores, passando por suas propriedades assosciated tornou-se um gargalo (E isso nunca vai acontecer, eu garanto), você mesmo deve começar a considerar deixar outra coisa senão as propriedades tocar suas variáveis ​​de apoio diretamente.

NET desenvolvedores podem usar propriedades automáticas para impor isso desde que você não pode sequer ver as variáveis ​​de apoio em tempo de design.

Respondeu 18/08/2008 em 18:43
fonte usuário

votos
6

eu encontrei usando setters / getters fiz o meu código mais fácil de ler. Eu também gosto do controle dá quando outras classes usar os métodos e se eu mudar os dados da propriedade irá armazenar.

Respondeu 18/08/2008 em 18:37
fonte usuário

votos
6

Eu posso estar errado porque eu sou autodidata, mas eu nunca usuário propriedades públicas em minhas aulas de Java, eles estão sempre privada ou protegida, de modo que o código externo deve acessar por getters / setters. É melhor para fins de manutenção / modificação. E para o código de classe dentro ... Se o método getter é trivial eu uso a propriedade directamente, mas eu sempre usar os métodos setter porque eu poderia facilmente adicionar o código para acionar eventos se eu quiser.

Respondeu 06/08/2008 em 15:43
fonte usuário

votos
5

Eu gosto da resposta por cmcculloh , mas parece que o mais correto é a resposta por Greg Hurlman . Use getter / setters todo o tempo se você começar a usá-los a partir do getgo e / ou são usados para trabalhar com eles.

Como um aparte, eu pessoalmente acho que o uso de getter / setters torna o código mais fácil de ler e depurar mais tarde.

Respondeu 15/09/2008 em 10:46
fonte usuário

votos
5

Bem, parece que com a implementação padrão C # 3.0 propriedades, a decisão é tomada por você; Você tem que definir a propriedade usando a propriedade setter (possivelmente privada).

Eu pessoalmente só uso o membro-behind privada quando não fazê-lo seria fazer com que o objeto cair em um menos de estado desejável, como quando a inicialização ou quando o cache / carregamento lento está envolvido.

Respondeu 01/08/2008 em 17:56
fonte usuário

votos
4

Como afirmado em alguns dos comentários: Às vezes, você deve, às vezes, você não deve. A grande parte sobre variáveis ​​privadas é que você é capaz de ver todos os lugares que eles são usados ​​quando você mudar alguma coisa. Se o seu getter / setter faz algo que você precisa, usá-lo. Se não importa se decidir.

Caso contrário poderia ser feito que se você usar o getter / setter e alguém muda o getter / setter eles têm que analisar todos os lugares do getter e setter é usado internamente para ver se ele mexe alguma coisa.

Respondeu 01/08/2008 em 18:01
fonte usuário

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more