Existe um termo usado quando variáveis ​​internas são declaradas públicas e acessíveis?


10

Se alguém escreve código para que uma variável interna $ _fields seja acessível sem o uso de métodos getter / setter, existe um termo adequado para descrevê-lo?

Algo educado o suficiente para usar com gerenciamento :)


9
Falta de encapsulamento?
Oded

@Oded Eu acho que você está certo - a falta de / pobre encapsulamento descreve-lo bem
PeterB

As duas frases em que pensei ao tentar responder a essa pergunta foram "abstração com vazamento" e "escopo livre" - a que cada uma delas se refere (fora da minha cabeça)?
PeterB

11
Abstração com vazamento é quando você tenta abstrair um conceito, mas ele realmente não funciona - os conceitos subjacentes ainda vazam (ORMs sobre SQL e estruturas da Web sobre HTTP / HTML tendem a ser abstrações com vazamento).
Oded

@PeterB - para adicionar à explicação de Oded, consulte o seguinte: joelonsoftware.com/articles/LeakyAbstractions.html
Joris Timmermans

Respostas:


30

Expor os membros privados nunca é uma coisa boa na sociedade educada ...

Essa prática é a falta de / encapsulamento ruim.


6
+1, bem, você não deixaria seus soldados no escritório, não é?
StuperUser

6
-1: O encapsulamento realmente aconteceu e aconteceu bem. Mas não foi documentado através do código fonte da maneira comumente aceita. Algumas linguagens (como Python) não possuem variáveis ​​verdadeiramente privadas, mas ainda praticam encapsulamento.
S.Lott

6
@Oded: Encapsulamento é um conceito de design . Diferentes idiomas têm diferentes implementações do conceito. Um idioma com uma declaração privada permite uma implementação. Uma linguagem de programação funcional com objetos sem estado pode ter uma implementação diferente. O Python (que falta private) tem mais uma implementação do conceito de encapsulamento.
S.Lott

11
@S Lott; Oded - O encapsulamento é bom e confiar no código em que variáveis ​​privadas são freqüentemente acessadas diretamente de outras classes é um encapsulamento ruim. Em python, você faz isso acessando variáveis ​​privadas com nome diferente de outra classe ou ignorando as convenções de um único prefixo de sublinhado (embora se seu getter estiver fazendo outro comportamento; realmente deve ser usado __para identificar nomes). Outras linguagens também podem ter um encapsulamento ruim, por exemplo, reflexão em Java e aritmética de ponteiros em C ++ para obter variáveis ​​privadas. Python simplesmente não cria a sintaxe para fazê-lo tão complicado.
dr jimbob

2
@drjimbob: O código Python raramente usa __nomes diferentes. Sem o __, o design ainda reflete um bom encapsulamento. Afirmar que "público" significa "falta de / encapsulamento ruim" está errado. O conceito ainda está presente. O código fonte não possui decoração apropriada.
S.Lott 6/12

10

Além da falta de encapsulamento já mencionada por Oded, dependendo da linguagem de programação e de seus paradigmas, também podem ser "dados antigos simples" (onde não é necessariamente um cheiro antipadrão ou de código).



2

É chamado de bolsa de propriedade.

Geralmente é usado para armazenar um conjunto de propriedades talvez relacionadas (cada uma delas pode ser potencialmente um objeto de classe que possui ou não especificadores de acesso apropriados). Mas a estrutura circundante é apenas um saco de propriedades.


2

É chamado de "não seguir um padrão de codificação específico".

O OP escreveu:

uma variável interna $ _fields está acessível sem o uso de métodos getter / setter

Isso pode ser contra o seu padrão e, portanto, pode ser um cheiro de código. Mas não é necessariamente um encapsulamento ruim. Expor uma variável interna (como em "apenas uso interno") sobre getter e setters para o mundo externo seria ainda pior.

A questão é: deve $_fieldsser acessível para o mundo exterior?

Nesse caso, temos um caso em que você adicionaria métodos getter / setter. Esses métodos não encapsulam nada além do fato de $_fieldsser uma variável de algum tipo (em oposição a algo calculado / buscado / etc. Em tempo real). Dependendo do idioma, você provavelmente ainda vazará o tipo (também conhecido como detalhe de implementação) para o exterior. Se você sempre deseja getters / setters, ou apenas quando "necessário", é um problema padrão de codificação.

Se não$_fields deve estar acessível, não acesse. Se você deve impedir que outras pessoas o acessem no nível do idioma (privado e amigos) ou não (o que pode facilitar a depuração em determinadas circunstâncias) é - novamente - um problema padrão de codificação.

A questão do encapsulamento é inteiramente ortogonal a isso. Violar o encapsulamento é absolutamente possível com getters e setters. É ainda mais fácil entrar, porque os alarmes da maioria das pessoas não tocam quando eles veem vários getters e setters - código que aparentemente segue as práticas recomendadas. Código, que pode muito bem introduzir muito mais dependências nos detalhes da implementação interna do que uma variável chamada $_fieldsque passa a não ser especificada como private.

Sou fã de más analogias: chamar esse pobre encapsulamento é como chamar alguém que tem uma arma de assassino.



-2

se seus métodos setter / getter não passam de

void setfoo(bar){foo=bar;}
foo getfoo{return foo;}

então, apenas criar uma variável púbica é apenas salvar algumas digitações fora de alguns casos extremos onde a diferença é importante.


3
Só porque isso é tudo o que seus getters e setters fazem agora não significa que é assim que sempre será. E se adicionar validação a um setter requer vasculhar dezenas de milhares de linhas de código para encontrar em qualquer lugar que a propriedade seja acessada, você instantaneamente explodirá a dúzia de segundos que você salvou, evitando propositalmente o encapsulamento pela primeira vez.
Plutor

@ Professor: Se isso é tudo o que o objeto fará (por exemplo, porque representa uma mensagem enviada para outro processo ou um registro em um banco de dados), tudo bem; essas são coisas que devem ser altamente conservadas.
Donal Fellows
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.