Click here to Skip to main content
12,813,994 members (33,987 online)
Rate this:
Please Sign up or sign in to vote.
See more: OOP
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 7:37am
Edward 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 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.
SAKryukov 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.
Edward Nutting 21-Feb-12 15:45pm
Thank you :)
SAKryukov 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. :-)
Rate this: bad
Please Sign up or sign in to vote.

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:


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.
Espen Harlinn 22-Feb-12 14:54pm
Excellent reply :)
SAKryukov 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
Naerling 22-Feb-12 17:11pm
Great, my 5!
SAKryukov 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.
SAKryukov 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. :-)
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.
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.
SAKryukov 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.

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.
SAKryukov 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.
SAKryukov 22-Feb-12 17:55pm
Thank you very much. :-)
SAKryukov 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.
TRK3 22-Feb-12 18:04pm
Great. Thanks!
Rate this: bad
Please Sign up or sign in to vote.

Solution 2

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:[^].

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:[^].

Espen Harlinn 22-Feb-12 14:56pm
An excellent reply, as usual, Sergey :)
SAKryukov 22-Feb-12 14:59pm
Thank you very much, Espen.
Naerling 22-Feb-12 17:14pm
Excellent, my 5.
Chrene91 22-Feb-12 17:16pm
This cleans things up thx for the effor both you guys :)
SAKryukov 22-Feb-12 17:19pm
Thank you, Naerling.
SAKryukov 22-Feb-12 17:23pm
You are very welcome.

Good luck, call again.

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

    Print Answers RSS
Top Experts
Last 24hrsThis month

Advertise | Privacy | Mobile
Web02 | 2.8.170308.1 | Last Updated 22 Feb 2012
Copyright © CodeProject, 1999-2017
All Rights Reserved. Terms of Service
Layout: fixed | fluid

CodeProject, 503-250 Ferrand Drive Toronto Ontario, M3C 3G8 Canada +1 416-849-8900 x 100