abstract private

[Nick George]

All Observers advance in the same way. Among other things, the run int check(). Each subclass checks in a different way, but the subclass itself has no buisness running check. Thus, I want it to be abstract and private to the abstract class. Where's the flaw in my thinking? I understand why you can't override an invisible method, so is this indictaive of a design flaw of my heirarchy?
[ October 11, 2004: Message edited by: Nick George ]

[Jim Yingst]

I understand why you can't override an invisible method, so is this indictaive of a design flaw of my heirarchy?

Ummm... private and abstract are fundamentally incompatible modifiers. So I'd say that yes, there's probably a flaw somewhere in your thinking. Except I really have no idea what you're actually talking about here. What check() method? Are you talking about java.util.Observable, or something else? Please explain.
[ October 12, 2004: Message edited by: Jim Yingst ]

[Carol Enderlin]

Originally posted by Nick George:
Each subclass checks in a different way, but the subclass itself has no buisness running check.

You're right, the subclass has no business running the abstract method from the parent class, but you don't have to enforce it. Just give the abstract method the modifier that will be appropriate for the methods in the subclasses (public?). You can try it yourself, code it up and see the compiler error you get when the subclass tries to call an abstract method from the parent.

[David Harkness]

Your logic makes sense: the subclass provides the implementation of check() but shouldn't be calling the method itself. However, Java doesn't have this option. A method is always visible to -- and thus can be called by -- the class in which it is defined.

Simply make the method "abstract protected" and put a warning in the JavaDoc if you feel it is warranted. If you absolutely must ensure that the method is called by the superclass, you could create a severe hack:

Create a new Throwable

Print its stack trace into a StringBuffer

Parse the buffer for the expected method

Throw an exception if not found

Note that I did say "severe."
[ October 12, 2004: Message edited by: David Harkness ]

[Nick George]

Hey... thanks to Jim for reminding me of this thread's existance... No, the Observer is my own class. Every subclass of Observer runs the method check() at exactly the same time. The abstract class Observer is the ONLY thing I want to be able to call check(). Unfourtunately, each subclass of Observer needs to check something different.

Perhaps a bit of context: I am building a package I call "environment." Everytime I make a JOGL game, I end up rewriting the same 100 lines of set up code, just with slight modifications. So I'm trying to make a generic World to which a user can add new Things (implementers of interface Thing with method advance(double millis) ). How exactly they are advanced is up to the subclass of Thing's advance method. I am able to specialize my world via my WorldAdapter, with methods called by world such as timedEvent(long clock), advanceEvent(double millis), and finally codedEvents. Observers focus around codedEvents. What if I want to do something special when the world.... Fuck! I just realized this isn't going to work...


Alright, back to the drawing board. The problem:

-Worlds are completely encapuslated (don't know if that's the right buzzword... ever'thin's private).

-I want to be able to check for any condition I may want to check for 15 years from now.

My original plan was to have the user lob a subclass of observer into the world, which, at every cycle would check its condition, and fire an event if it was reached. This, of course, was founded on the belief that being added to a List in World suddenly gave the addee unlimited access to all the secrets of the World.

Possible solutions and the problems with them:

1. Have the adapter extract the information from the adapter and run the checks every advanceEvent. [ugly, violates encapsulation, checks ought to be held internally]

2. Make pertinent information protected, extend world, and tack the checks on the end of advance. [Ugly, ugly, ugly! I want Worlds to be self sustaining entities, and not need to be extended]

3. The hell with encapsulation, make everything public, and lob my observers into the world with the know-how to do the checks. [already stated problem]


Er?
[ October 13, 2004: Message edited by: Nick George ]