Click here to Skip to main content
Rate this: bad
good
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 6:37am
Chrene913.4K
Comments
Edward Nutting at 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.
SAKryukov at 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
Edward Nutting at 21-Feb-12 15:45pm
   
Thank you :)
SAKryukov at 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
Rate this: bad
good
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:
 
"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.
  Permalink  
Comments
Espen Harlinn at 22-Feb-12 14:54pm
   
Excellent reply :)
SAKryukov at 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
Naerling at 22-Feb-12 17:11pm
   
Great, my 5!
SAKryukov at 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 at 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 at 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
SAKryukov at 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 at 22-Feb-12 18:04pm
   
Great. Thanks!
SAKryukov at 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 at 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.
SAKryukov at 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 at 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 at 22-Feb-12 17:55pm
   
Thank you very much. :-) --SA
Rate this: bad
good
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:
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
  Permalink  
Comments
Espen Harlinn at 22-Feb-12 14:56pm
   
An excellent reply, as usual, Sergey :)
SAKryukov at 22-Feb-12 14:59pm
   
Thank you very much, Espen. --SA
Naerling at 22-Feb-12 17:14pm
   
Excellent, my 5.
SAKryukov at 22-Feb-12 17:19pm
   
Thank you, Naerling. --SA
Chrene91 at 22-Feb-12 17:16pm
   
This cleans things up thx for the effor both you guys :)
SAKryukov at 22-Feb-12 17:23pm
   
You are very welcome. Good luck, call again. --SA

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

  Print Answers RSS
Your Filters
Interested
Ignored
     
0 Guruprasad.K.Basavaraju 450
1 Sergey Alexandrovich Kryukov 325
2 Shai Vashdi 318
3 OriginalGriff 265
4 Peter Leow 171
0 Sergey Alexandrovich Kryukov 9,109
1 OriginalGriff 5,290
2 Peter Leow 4,010
3 Maciej Los 3,535
4 Abhinav S 3,263


Advertise | Privacy | Mobile
Web04 | 2.8.140415.2 | Last Updated 22 Feb 2012
Copyright © CodeProject, 1999-2014
All Rights Reserved. Terms of Use
Layout: fixed | fluid