Skip to main content

(Not So) Stupid Questions 18: Reverse Access Modifiers

August 16, 2007


Editor's note: Sometimes the most interesting discussions begin when someone says, "This may be a stupid question, but ...." If the person asking the question has taken the time to think about the problem before asking, the question is often not stupid at all. The uncertainty points out an ambiguity in the specs, holes in the docs, or a search for how more experienced programmers might address a particular problem. From time to time, we will print one of the "(Not So) Stupid Questions" we receive and invite our readers to answer the question in the feedback section.

Remember that new people are joining the Java community all the time and may be looking for help from those with more experience. Also, those who began with Java as their first language can benefit from those coming to the community with experience in other languages. As always, answer the questions with kindness. You are also welcome to submit your questions to


This may be a stupid question, but ... "What do you do when you want to avoid any calls from inside your own methods to outside classes?"

First Thoughts

We can define a method private. This is a protection against calls from outside of the class declaring this method. But what do you do when you want to avoid any calls from inside the method to any outside class, other than maybe to the java.lang classes that are fundamental to almost any application?

Why would you want to do this? And why wouldn't it be enough to say, "If you don't want your methods to make outside calls, then just don't make any?" Let me explain.

What I want is to prohibit my own method from calling any other outside class, specifically, to be able to declare calling grants. This idea comes from both practical needs and theoretical ideas:

  • Practical because sometimes I have to refactor code that lacks maturity or polish. I need to eliminate dependencies, and that means reining in outside calls. I also want to eliminate cyclic dependencies, where class A calls class B, and class B calls A.

    When a project is complex, we need a lot of protection from ourselves. I would appreciate such protection if I were coding a space shuttle navigation program, for instance. I imagine the astronauts would like it too.

  • The idea has a theoretical basis, too, because I'm studying the science of systems (cybernetics) that describes their structuration and communication. And I think that our modeling approach (OO from OMG and more Java) doesn't match a typical system model. Of course, I'm not an expert, so maybe I'm mistaken.

    A system (or subsystem) is able to protect its state and structuration from the context. It's what we have with the encapsulation (getters, setters, private modifiers, etc.).

    And a system manages its communication using ports that can receive and send message to the context. These ports can be open or closed and can select messages (like on network architecture). We can create methods on a class that look like ports, with combination of getters/setters, an observable-observer pattern, etc. Some methods are dedicated to the communication with other functional classes in our program--but others exist only to recompute the state of the class, or perform operations like computing a mathematical function.

    These latter methods shouldn't call anything else, except perhaps some some java.* packages and objects from the business logic layer of my application.

I hope I've been clear enough. I would like to now what Java developers and modeling specialists think about this idea:

How would you create "reverse" access modifiers?

width="1" height="1" border="0" alt=" " />
Related Topics >> Programming   |