I have a issue where I'm working with a particular interface for quite a lot of things. However, I have a particular method that I want to be available only to a particular group of classes (basically, an internal
method).
interface IThing {
function thisMethodIsPublic():void;
function thisMethodShouldOnlyBeVisibleToCertainClasses():void;
}
The problem is, there is no way to add access modifiers (i.e. public, private, internal) in an interface - at least not in ActionScript 3.0.
So I'm wondering what would be the best practice here? It seems like bad form to make this internal method public, but I need it to be a part of the interface so I can guarantee that classes that implement it have this internal method.
Thanks for your help!
One possible idea I just thought of would be to define a second interface for the internal method:
That way the method would not be visible without type casting when working with
IThing
, but would be when you explicitly type cast asIInternalThing
. This doesn't really solve the problem but it makes that method a little more hidden.Answer: Define two interfaces, and keep the 'private' functions in the second interface. If ActionScript supports inheritance for interfaces, then define the 'private' interface as extending the 'public' interface.
Maybe use namespaces instead of (or in addition) to your interface. Just a thought.
Sorry to keep answering my own question but... Another possibility, kind of crazy, would be to create a sort of lock and key for the method I want to make private similar to the
SingletonEnforcer
often used in AS3.This seems like overkill to me but I tested it and it works! Classes external to the
InternalKey
can see the method but cannot call it. It also guarantees that the interface makes use of the method in question instead of having to typecast to the second interface.It is also possible to make the second interface be an internal interface instead of using the Internal key.
Actually, both of these are not exactly what I need because I wanted to make the method exposed to a nested package within the package where
IThing
would be, so basically I want to use custom namespaces here but I can't. I'm probably going to have to move the classes in the nested package back into the same pacakge asIThing
.Today I've encountered same problem. Fortunately I had opportunity to make a superclass instead of interface. Instead of using this:
I wrote this:
Of course it's only possible if classes that implement IPhysicalObject interface do not extend any other class. I think that is another possible solution.