should I use accessors or not?

Question

5.00/5 (2 votes)

See more:

I have programmed for about 2-3 years now and actually I am developing a game in actionscript atm. I have a character class which have some fields like name, level, experience, damage, defence and so on. right now I have made them protected so the deriving classes can see them, and I have used getters and setters to encapsulate them, so other classes only can see the getters. However in actionscript it seems that you can't make accessors protected, so they must be public. But why should I use accessors at all if anybody can just see them and edit them anyway? Should I just skip the encapsulation and just go with public fields and encapsulate the ones who need to do some other statements when set. For instance if I increase the experience field it should check for a level up while increasing.

I like accessors in c# because they make the coding easier as you can't see private/protected accessors in other classes.

It would be nice to have some more experienced programmers opinion on accessors.

Posted 21-Feb-12 6:37am

Chrene91

Add a Solution

Comments

Ed Nutting 21-Feb-12 13:43pm

This is only a brief comment but (as you rightly point out) getter/setter accessors can be used for more than just getting and setting a variable - they allow you do do some processing (e.g. updating a cached list) every time the property is "retrieved" or set. Furthermore, accessors (at least in C#) don't have to have both a get and a set property - they may only have one or other (though why you would have a set without get I don't know...any examples anyone?) but back to my point. You can use accessors to allow external classes to get the value of a field without them being able to change it (by having a get but no set...as the C# System libraries frequently, and often annoyingly, make use of...). Hope this helps clear things up a bit but as I say, it's just my thoughts on the topic.

Sergey Alexandrovich Kryukov 21-Feb-12 15:42pm

This is all correct; so I would up-vote it if it was an answer. Something could be added, but just a little.
--SA

Ed Nutting 21-Feb-12 15:45pm

Thank you :)

Sergey Alexandrovich Kryukov 21-Feb-12 17:31pm

I actually added some information on the topic and some explanations on the philosophy of OOP related to the topic. I credited your comment in my answer.

Please take a look; you might find it somewhat interesting. :-)
--SA

2 solutions

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

TRK3 · Accepted Answer · 2012-02-21T11:19:00

Solution 1

Just because the language doesn't provide a means of protection / encapsulation, doesn't mean you should abandon accessors.

I learned OOP and the importance of encapsulation directly from Barbara Liskov.

My first professional programming job after that was in C. Even though we were writing in C, we wrote Object Oriented code. We had data structures and functions (or macros) that operated on those structures. If you wanted to manipulate one of those structures or set or get data in them, you used the function (or macro) for that. You NEVER EVER, ON PAIN OF DEATH, accessed the data directly.

Why? Because we wanted to be able to change the underlying representations if necessary without having to re-write the code that used those objects.

The simple example is:

Suppose you have a rectangle object but you aren't sure if it's going to be more efficient to store it as x, y, width and height, or to store it as top, left, bottom, right.

If you code it one way and then find that your graphical rendering code (or something) would be faster if you rendered it the other way, then you can change the underlying representation without effecting anything.

Or, as Edward suggests, you might find that you want to cache certain things. If you set and get everything via the accessors then you can implement a cache for the things you decide that need to be cached when you decide it's needed.

The basic lesson is:

If you write accessors and strictly enforce that only accessors are used to access the data, then you are free to change implementation details as needed without effecting any other code.

It means you don't have to make all the low level design decisions up front. You can change implementation as necessary.

The ONLY time you wouldn't provide accessors is when you KNOW ABSOLUTELY that you are NEVER going to want to do something else when that data is set or get and you are NEVER going to want to change it's underlying representation. The longer you expect your code to leave, the more important it is to provide accessors.

Just because the language doesn't provide a means of protecting something doesn't mean you can't put a huge comment there that says:

"I RESERVE THE RIGHT TO CHANGE THIS IMPLEMENTATION AT ANY TIME. USE ACCESSORS ONLY. ACCESSING THE DATA DIRECTLY IS GUARANTEED TO RESULT IN NON-FUNCTIONING CODE EVENTUALLY."

If I saw something like that in a class definition I'd think twice about directly accessing anything the original writer told me not to.

Posted 21-Feb-12 11:19am

TRK3

Comments

Espen Harlinn 22-Feb-12 14:54pm

Excellent reply :)

Sergey Alexandrovich Kryukov 22-Feb-12 15:03pm

Good points and nice explanation.
You also justified the idea I tried to explain in my answer, not sure if I was clear enough or not: the syntax feature as a support of programming as a human activity. The passage "I RESERVE THE RIGHT..." should give a pretty good idea and what you and me meant.

My 5
--SA

Sander Rossel 22-Feb-12 17:11pm

Great, my 5!

Sergey Alexandrovich Kryukov 22-Feb-12 17:22pm

I just wanted to add that you should take a closer look at ActionScript, because your note "because the language doesn't provide a means of protection / encapsulation" looks correct but redundant/irrelevant, just because this language certainly provides both, and pretty well.
--SA

TRK3 22-Feb-12 17:41pm

Interesting, I have never programmed ActionScript.

OP said "in actionscript it seems that you can't make accessors protected" -- so I incorrectly assumed the language lacked the concept.

In any case, my comments really were language agnostic.

You can and should do the right thing even if the language doesn't natively support it.

Sergey Alexandrovich Kryukov 22-Feb-12 17:54pm

I only said that the language provides good encapsulation and protection related to it, but I'm not sure about protected or private access modifier just for getters and setters. It is available form other members though. I'm not sure, may be some newer version changed things a bit. So OP is probably right about this limitation. But -- having this limitation does not yet mean lack of encapsulation itself.

I referenced pretty good discussion in my answer, you can take a look.
--SA

Sergey Alexandrovich Kryukov 22-Feb-12 18:02pm

"You can and should do the right thing even if the language doesn't natively support it."

This was very important thing to say.

I used to do a lot of this: working with the language where some expressive capabilities or discipline are not supported, bring the good ideas from different languages and implement them on the level of libraries or design patterns. If you look at my cycle of 3 CodeProject articles on enumerations -- this is exactly the case. I used the ideas of Ada and Delphi Pascal to bring them and strengthen .NET.

Please take a look if you are curious -- it's pretty interesting, I think.
--SA

TRK3 22-Feb-12 18:04pm

Great. Thanks!

Sergey Alexandrovich Kryukov 22-Feb-12 17:27pm

By the way, Barbara Liskov is one of the computer scientists I respect the most, of all times and peoples. I'm glad that your learned from her well. :-)
--SA

TRK3 22-Feb-12 17:35pm

I took two courses from her, an undergraduate course on OOP and a upper-level/graduate-level course on language design. She defintely shaped my thinking in both those areas. Not only is she a brilliant computer scientist, she is also an excellent teacher -- you don't always find both in one person.

Sergey Alexandrovich Kryukov 22-Feb-12 17:45pm

That is great. Did you graduate from MIT? (I live in Massachusetts, know pretty well what is that; and I graduated from M.I.P.T.)
Actually, me too, but I wasn't so happy. I learned about her inventions and works in some books, when I was learning Ada (Ada-83), mostly during 1980x.

Believe or not, but I was the author of the very early implementation of fully-fledged structured exception handling (like in CLU and Ada), when it was not yet introduced in C++ (!). I wrote this part in inline assembly; and it was the part of my stand-along multithreading system; and I developed it when threads were not yet introduced in Linux (1993).

I really think that the structural exception handling, as it was invented by Barbara Liskov, is one of the greatest inventions in software, of all times and peoples, may be even more fundamentally important then OOP. Barbara's Turing Award was more than deserved, I think.

--SA

TRK3 22-Feb-12 17:52pm

Yes, got my Bachelors and Masters there in '87. (Then moved back to California as fast as possible...)

I've always been very impressed with your comments and answers here -- I'm not at all surprised to you were involved in that sort of thing.

I agree with you on structured exception handling as a great invention. And, yes, she definitely deserved the Turing award.

Sergey Alexandrovich Kryukov 22-Feb-12 17:55pm

Thank you very much. :-)
--SA

Sergey Alexandrovich Kryukov · Accepted Answer · 2012-02-21T11:29:00

Almost everything is explained by Edward in his comment to the question. I will add just a bit.

This is a pretty interesting discussion of the rationale for different access modifiers:
http://www.actionscript.org/forums/archive/index.php3/t-113383.html[^].

Pay attention for description of cases where different access for read and assignment operations can be useful. It is often used in C++, C#, Delphi Pascal, etc.

By the way, I would advice not to forget internal access modifiers which defined access public if accessed withing the package and like private when accessed across packages. The idea is this: you should not provide more access than it is really needed.

I should also note that the common practice is to use getters or setters even when the access methods are trivial and logically equivalent to using just the fields. In this case, these method just provide a clue that a public/internal getter/setter interface is abstracted from the (private) data structure, and non-trivial access (get or set) algorithms can be added at any moment later. Ideologically, this is similar to using empty base classes or interfaces: they just carry some semantic representing the elements of reality and named according to a denotation taken from natural language; it also serves as a placeholder for the class or interface member which may help to express the semantics during later development. This is a way of using computer language syntax in order to support not only the run-time semantics of code, but the process of development.

Finally, I want to note on the following part of the question:

Chrene91 wrote:
Should I just skip the encapsulation and just go with public fields…?

It is apparent that you are trying to use the term encapsulation in some very narrow sense which is neither default nor customary. Usually, the implied sense of this term in OOP does not allow you to "skip encapsulation" as soon as you simply use classes in any sensible way. It generally means information hiding understood in terms of code maintenance and discipline. Please see:
http://en.wikipedia.org/wiki/Encapsulation_in_object-oriented_programming[^].

—SA