If someone writes code so that an internal variable $_fields is accessible without using getter/setter methods, is there a proper term used to describe that?
Something polite enough to use with management :)
If someone writes code so that an internal variable $_fields is accessible without using getter/setter methods, is there a proper term used to describe that?
Something polite enough to use with management :)
Exposing ones private members is never a good thing in polite society...
This practice is the lack of/poor encapsulation.
private
) has yet another implementation of the concept of encapsulation.
__
for name mangling). Other languages can have poor encapsulation too, e.g., reflection in Java and pointer arithmetic in C++ to get at private variables. Python just doesn't make the syntax to do it that cumbersome.
Dec 6, 2011 at 15:22
__
name mangling. Without the __
, it the design still reflects good encapsulation. Claiming that "public" means "lack of/poor encapsulation" is wrong. The concept is still present. The source code lacks appropriate decoration.
Besides the lack of encapsulation already mentioned by Oded, depending on the programming language and its paradigms it could also be "plain old data" (where it isn't necessarily an antipattern or code smell).
I've heard the term "naked object" before.
Its called a property bag.
Usually it is used to hold a set of maybe related properties (were each may potentially be a class object that has appropriate access specifiers or not). But the surrounding structure is just a bag of properties.
It's called "not following a specific coding standard".
The OP wrote:
an internal variable $_fields is accessible without using getter/setter methods
That might be against your standard, and (thus) it might be code smell. But it is not necessarily poor encapsulation. Exposing an internal (as in "only of internal use") variable over getter and setters to the outside world would be even worse.
The question is: should $_fields
be accessible for the outside world?
If so, we have a case where you would add getter/setter methods. These methods do not encapsulate anything but the fact that $_fields
is a variable of some kind (as opposed to something calculated/fetched/etc. on the fly). Depending on the language, you'll probably still leak the type (aka an implementation detail) to the outside. Whether you always want getters/setters, or only when "needed" is a coding standard issue.
If $_fields
should not be accessible, then, well, don't access it. Whether you should keep others from accessing it on the language level (private and friends) or not (which might ease debugging in certain circumstances) is - again - a coding standard issue.
The issue of encapsulation is entirely orthogonal to this. Violating encapsulation is absolutely possible with getters and setters. It's even easier to slip into, because most people's alarm bells don't ring when they see a bunch of getters and setters - code that's seemingly following best practices. Code, that might very well introduce much more dependencies on internal implementation details than a variable called $_fields
that happens not to be specified as private
.
I'm a fan of bad analogies: Calling that poor encapsulation is like calling someone who holds a gun a murderer.
if your setter/getter methods are nothing more than
void setfoo(bar){foo=bar;}
foo getfoo{return foo;}
then just making a pubic variable is just saving some typing outside of a few edge cases where the difference matters.