10

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 :)

9
  • 9
    Lack of encapsulation?
    – Oded
    Dec 6, 2011 at 9:54
  • @Oded I think you're right - lack of/poor encapsulation describes it well
    – PeterB
    Dec 6, 2011 at 9:58
  • The two phrases I thought of while trying to answer this question were "leaky abstraction" and "loose scoping" - what do each of those refer to (outside my head)?
    – PeterB
    Dec 6, 2011 at 10:07
  • 1
    Leaky abstraction is when you try to abstract a concept but it doesn't really work - the underlying concepts still leak out (ORMs over SQL and web frameworks over HTTP/HTML tend to be leaky abstractions).
    – Oded
    Dec 6, 2011 at 10:24
  • @PeterB - to add to Oded's explanation, see this: joelonsoftware.com/articles/LeakyAbstractions.html Dec 6, 2011 at 10:32

7 Answers 7

30

Exposing ones private members is never a good thing in polite society...

This practice is the lack of/poor encapsulation.

10
  • 6
    +1, Well, you wouldn't get your privates out in the office would you?
    – StuperUser
    Dec 6, 2011 at 10:02
  • 6
    -1: Encapsulation really did happen and happened well. But it wasn't documented through the source code in the commonly accepted way. Some languages (like Python) lack truly private variables, yet still practice encapsulation.
    – S.Lott
    Dec 6, 2011 at 10:59
  • 6
    @Oded: Encapsulation is a design concept. Different languages have different implementations of the concept. A language with a private declaration permits one implementation. A functional programming language with stateless objects might have a different implementation. Python (which lacks private) has yet another implementation of the concept of encapsulation.
    – S.Lott
    Dec 6, 2011 at 13:07
  • 1
    @S Lott ; Oded - Encapsulation is good and relying on code where private variables are frequently directly accessed from other classes is poor encapsulation. In python, you do this by accessing name-mangled private variables of another class or ignoring conventions of a single underscore prefix (though if your getter is doing other behavior; really should use __ 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.
    – dr jimbob
    Dec 6, 2011 at 15:22
  • 2
    @drjimbob: Python code rarely uses __ 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.
    – S.Lott
    Dec 6, 2011 at 17:05
10

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).

0
4

I've heard the term "naked object" before.

2
  • 1
    It is certainly a confusing way to name those considering the Naked Objects Pattern
    – Matthieu
    Dec 10, 2011 at 14:39
  • 1
    Yeah, that got me confused as well.
    – Raku
    Dec 12, 2011 at 14:39
2

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.

2

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.

1

I would call such variables public member variables.

-2

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.

2
  • 3
    Just because that's all your getters and setters do now doesn't mean that's the way it'll always be. And if adding validation to a setter requires combing through tens of thousands of lines of code to find everywhere that property is accessed, you'll instantly blow the dozen seconds you saved yourself by purposely avoiding encapsulation the first time.
    – Plutor
    Dec 6, 2011 at 15:09
  • @Plutor: If that's all the object will ever do (e.g., because it represents a message sent to another process or a record in a database) then it's OK; those are things that should be highly conserved. Dec 6, 2011 at 15:45

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.