Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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

share|improve this question
9  
Lack of encapsulation? –  Oded Dec 6 '11 at 9:54
    
@Oded I think you're right - lack of/poor encapsulation describes it well –  PeterB Dec 6 '11 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 '11 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 '11 at 10:24
    
@PeterB - to add to Oded's explanation, see this: joelonsoftware.com/articles/LeakyAbstractions.html –  Joris Timmermans Dec 6 '11 at 10:32
show 4 more comments

7 Answers

up vote 31 down vote accepted

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

This practice is the lack of/poor encapsulation.

share|improve this answer
6  
+1, Well, you wouldn't get your privates out in the office would you? –  StuperUser Dec 6 '11 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 '11 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 '11 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 '11 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 '11 at 17:05
show 5 more comments

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.

share|improve this answer
add comment

I would call such variables public member variables.

share|improve this answer
add comment

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.

share|improve this answer
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 '11 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. –  Donal Fellows Dec 6 '11 at 15:45
add comment

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

share|improve this answer
1  
It is certainly a confusing way to name those considering the Naked Objects Pattern –  Matthieu Dec 10 '11 at 14:39
1  
Yeah, that got me confused as well. –  Raku Dec 12 '11 at 14:39
add comment

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.

share|improve this answer
add comment

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

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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