Fog Creek Software
Discussion Board




Encapsulation--to what extent?

I have a question about encapsulation.

I understand that if you have some abstract data type or object that it's often preferred to provide access to its members through routines (typically get*() and set*() routines). But how far should you go? If you provide these accessors publicly and tell the users of your object/ADT to use them, should use them too, even internally in the class or module definition?

And what about private data members? Should you go ahead and create private accessor routines for them and then call them internally instead of just accessing the data members directly?

How far should you go? What is your preference?

Phil Baroni has posse (of men clad in cut-off shorts following him and asking him out)
Friday, June 18, 2004

Depends on what you're doing...

I mean, come on, it's like saying "how should I put the walls together to make a house?"

Rick
Friday, June 18, 2004

For me, the main purpose of providing public 'accessors' is providing an interface, an API, to my class.

The purpose of providing an interface is to allow instantiators of this class to use this (hopefully simple) interface to do the work of the application.  They only need to know the details of the interface, not the internals of my class.

This provides some freedom/independence in  implementation.  If I know that user's will ONLY use the interface pieces to interact with my class, I have freedom how I implement the 'internals' of my class.  I can refactor the internals to use different/better/more-efficient data structures, and the useing code won't need to be modified.

So, the public 'accessors' are only provided for things needed in the interface.  If I am 'inside' the class, I already know all things about the internals of my class.  It would be silly for me, inside my class, to have to call public accessors merely to set or get data elements I already have 'local' access to.  It would also be a (small) performance hit -- several levels of calling indirection to do something I can already do with a simple assignment.

AllanL5
Friday, June 18, 2004

I've seen in both ways. To me, encapsulation has always been about being able to change what happens behind the scenes when data needs to be accessed. As such, I usually refrain from directly modifying private members within my own class outside of the method, because then if I wanted to change what happens when the data is accessed, I also have to change anywhere in my class that directly accesses it.

But, I'm sure that there could be grounds for a small performance hit, so if you are going for performance or writing a class that is well-defined, it probably doesn't matter if you internally access the private members (after all, that's what they are there for).

CF
Friday, June 18, 2004

"should use them too, even internally in the class or module definition?"

Sorry, that should be, "should you use them too, even internally in the class or module definition?"

Baroni Basher
Friday, June 18, 2004

I'd say: the main reason for implementing getters and setters is because you anticipate wanting to override them in inherited classes. If there's no way you'd ever need to override them then I wouldn't bother with them.

If you /do/ implement them though, you should use them consistently in all your methods, public or private, or else things might not behave the way you want when you do override them and it turns out a bunch of private methods aren't bothering to use the get/setters so aren't getting the benefit of the new overridden get/setters that actually do something more than just get/set.

Both the above comments apply to getters and setters for public or private values.

Matt
Friday, June 18, 2004


I'm more interested in the story behind your peculiar sig than encapsulation. Please divulge.

A Pterodactylus Ate My Baby
Friday, June 18, 2004

Basically in agreeance with what Matt said above --  don't implement getters/setters unless you find you need them. 

And even then, question whether you *really* need them. 

The Pragmatic Programmer website has a nice article, "Tell, Don't Ask", which might be of interest.

http://www.pragmaticprogrammer.com/ppllc/papers/1998_05.html

Kevin
Friday, June 18, 2004

Thanks everyone.

(As for the name, see: http://www.sherdog.com/fightfinder/fightfinder.asp?fighterid=278 and http://www.mixedmartialart.com/baroni.WMV )

Baroni Basher
Friday, June 18, 2004

Baroni Basher, you should just come clean and admit you want Phil Baroni to give you a 'pearl necklace' and a 'golden shower'...before corn-holing you, of course.

Baroni Basher Loves Phil Baroni
Monday, June 21, 2004

*  Recent Topics

*  Fog Creek Home