¿Se utiliza un término cuando las variables internas se declaran públicas y accesibles?

Si alguien escribe código para que se pueda acceder a una variable interna $ _fields sin utilizar los métodos getter / setter, ¿hay un término apropiado para describirlo?

Algo lo suficientemente educado como para usar con la administración :)

Exponer a los miembros privados nunca es algo bueno en una sociedad educada ...

Esta práctica es la falta de / pobre encapsulación.

Además de la falta de encapsulación ya mencionada por Oded, dependiendo del lenguaje de programación y sus paradigmas también podría ser "datos antiguos" (donde no es necesariamente un antipatrón o un olor a código).

He escuchado el término "objeto desnudo" antes.

Se llama bolsa de propiedades.

Por lo general, se usa para contener un conjunto de propiedades posiblemente relacionadas (donde cada una de ellas podría ser un objeto de clase que tenga o no los especificadores de acceso adecuados). Pero la estructura circundante es solo una bolsa de propiedades.

Se llama "no seguir un estándar de codificación específico".

El OP escribió:

Se puede acceder a una variable interna $ _fields sin utilizar métodos getter / setter

Eso podría estar en contra de su estándar, y (por lo tanto) podría ser olor a código. Pero no es necesariamente una pobre encapsulación. Exponer una variable interna (como en "solo de uso interno") sobre getter y setters al mundo exterior sería aún peor.

La pregunta es: ¿debería $_fieldsser accesible para el mundo exterior?

Si es así, tenemos un caso en el que agregaría métodos getter / setter. Estos métodos no encapsulan nada más que el hecho de que $_fieldses una variable de algún tipo (a diferencia de algo calculado / obtenido / etc. sobre la marcha). Dependiendo del idioma, es probable que aún filtre el tipo (también conocido como detalle de implementación) hacia el exterior. Si siempre quiere getters / setters, o solo cuando es "necesario" es un problema estándar de codificación.

Si no$_fields debe ser accesible, entonces, bueno, no acceda a él. Si debe evitar que otros accedan a él a nivel de idioma (privado y amigos) o no (lo que podría facilitar la depuración en ciertas circunstancias) es, nuevamente, un problema estándar de codificación.

El tema de la encapsulación es completamente ortogonal a esto. Violar la encapsulación es absolutamente posible con getters y setters. Es aún más fácil entrar, porque las campanas de alarma de la mayoría de las personas no suenan cuando ven un montón de captadores y establecedores, código que aparentemente sigue las mejores prácticas. Código, que bien podría introducir muchas más dependencias en los detalles de implementación internos que una variable llamada $_fieldsque no se especifica como private.

Soy fanático de las malas analogías: llamar a esa pobre encapsulación es como llamar asesino a alguien que tiene una pistola.

Llamaría a tales variables miembros públicos variables .

si sus métodos setter / getter no son más que

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

entonces solo hacer una variable púbica es solo guardar algo de tipeo fuera de algunos casos extremos donde la diferencia es importante.