decoration decoration
Stories

GROKLAW
When you want to know more...
decoration
For layout only
Home
Archives
Site Map
Search
About Groklaw
Awards
Legal Research
Timelines
ApplevSamsung
ApplevSamsung p.2
ArchiveExplorer
Autozone
Bilski
Cases
Cast: Lawyers
Comes v. MS
Contracts/Documents
Courts
DRM
Gordon v MS
GPL
Grokdoc
HTML How To
IPI v RH
IV v. Google
Legal Docs
Lodsys
MS Litigations
MSvB&N
News Picks
Novell v. MS
Novell-MS Deal
ODF/OOXML
OOXML Appeals
OraclevGoogle
Patents
ProjectMonterey
Psystar
Quote Database
Red Hat v SCO
Salus Book
SCEA v Hotz
SCO Appeals
SCO Bankruptcy
SCO Financials
SCO Overview
SCO v IBM
SCO v Novell
SCO:Soup2Nuts
SCOsource
Sean Daly
Software Patents
Switch to Linux
Transcripts
Unix Books

Gear

Groklaw Gear

Click here to send an email to the editor of this weblog.


You won't find me on Facebook


Donate

Donate Paypal


No Legal Advice

The information on Groklaw is not intended to constitute legal advice. While Mark is a lawyer and he has asked other lawyers and law students to contribute articles, all of these articles are offered to help educate, not to provide specific legal advice. They are not your lawyers.

Here's Groklaw's comments policy.


What's New

STORIES
No new stories

COMMENTS last 48 hrs
No new comments


Sponsors

Hosting:
hosted by ibiblio

On servers donated to ibiblio by AMD.

Webmaster
Java Access Modifiers | 451 comments | Create New Account
Comments belong to whoever posts them. Please notify us of inappropriate comments.
final protected methods
Authored by: greed on Thursday, May 03 2012 @ 09:56 PM EDT

Well, computers are very literal--which is why I get along with them. So the computer doesn't mind the apparent pointless "protected" method on a "final" class.

But wait, I've forgotten package scope.

Controlling Access to Members of a Class (link to docs.oracle.com!)

"protected" methods can be accessed by classes in the same package. So, in Java's case, "protected" on a "final" class is like not having an access control keyword at all--there's 4 access control contexts: the 3 class hierarchy ones (self, child, other) plus package.

[ Reply to This | Parent | # ]

Java Access Modifiers
Authored by: Anonymous on Thursday, May 03 2012 @ 11:27 PM EDT

There are three levels of access: private, protected, and public

Private methods may only be called by another instance of the class.

A class's protected methods may only be called objects which subclass the class, or objects whose class are in the same package.

Public methods may be called by any other object.

Private, protected, and public have corresponding, though not exactly the same, meanings when applied to Classes and variables.

Final means cannot be changed, generally. For instance a method marked "public final" means it can be accessed by any object, but objects of a subclass cannot override it.

So what's overriding? Let's say we are writing a library for simulating animal behavior. One thing we could do is create an Animal class and put in an abstract method "public abstract void makeNoise()". It's abstract because we don't write any code here. We then create our Cat class which subclasses Animal. Because Cat is a concrete class, we have to write the code to implement public void makeNoise() [the abstract disappears because there is implementing code.] We'll do the obvious { System.out.printLn("Meow"); }. Now we make a concrete Dog class, again subclassing Animal, and again implementing makeNoise, as follows: public void makeNoise() { System.out.println("Woof."); }

One might ask, so? This is called polymorphism, by the way, and it allows us to abstract the specific animal type, because whether the Animal is Dog, Cat, Duck, or CartoonPlatypus, we know we can call makeNoise() because that comes being a subclass of the Animal class.

Now we could have made the makeNoise method in Animal concrete and put in some code, in which case if the subclass does not rewrite it, and this is known as overriding, the code in the superclass is executed. For instance, let's put the following method in Animal public boolean isFourLegged() and our implementing code is "return true;". If we write a Man class, subclassing Animal, we will do the following:

@Override
public boolean isFourLegged() { return false; }

in this way we save a lot of effort by refactoring a common property into a common superclass, but can be specific when the subclass differs.

And this brings us to final. Since a class can be subclassed and public and protected methods overridden, we can change an object's behavior and this could raise security issues. For instance, if we can override the checkPassword method, our subclass could let everyone in by accepting everything.

When we want to make sure a method cannot be overridden, we put final in its signature.

Going back to our Animal class for our simulation, we may wish to have each animal have a flag for being alive. Inside the Animal class, we will put the following instance variable:

private boolean alive = true;

We will add the following method:

public boolean isAlive() { return alive; }

and we will add another method:

public final void dies() {
alive = false;
}

and now we are sure that none of the subclasses can have something else happen.

I hope this helps.

[ Reply to This | Parent | # ]

Groklaw © Copyright 2003-2013 Pamela Jones.
All trademarks and copyrights on this page are owned by their respective owners.
Comments are owned by the individual posters.

PJ's articles are licensed under a Creative Commons License. ( Details )