Thread: API singleton theory

Okay, i've been struggling with this for a while now so i thought i'd ask the experts.

I have a file Combat.java
Another file, Actions.java, uses methods stored in Combat.java
So i have a class, MethodProvider.java, which initializes the classes. I extend MethodProvider.java to use these variables.

Situation:


I know why this results in this error, but how can i do it correctly?
How would i make MethodProvider appropriate?

Well, clearly you are doing something very memory heavy, most likely some sort of recursion, in your dunkscripts.game.Actions() constructor. Go through that constructor (and the methods it calls) and see if you are forgetting anything in either recursion or looping (perhaps on line 10 of the Actions class).

Well without seeing the code where the recursion is done incorrectly, there is no way we can tell what you are doing wrong and provide help.


EDIT: Oh wait, I see what is happening. The problem is that Actions extends MethodProvider, but an Actions object is created when a new MethodProvider is created. So basically, when you create an Actions object, it creates an Actions object.

So I guess my question would be: Why do you think that either:
a) Actions needs to inherit from MethodProvider?
b) An Actions object needs to be created in your MethodProvider?

The way to fix this will depend entirely on how you have your project structured and how you are planning on using the Actions/MethodProvider objects.

Ok, well what you currently have I have no idea how to describe. It is inheritance, but not a practical use of inheritance.

It sounds like what you are wanting to do is create a class where you have variables that can be used throughout your project. There are a few tidbits about doing this. Namely, in order to be invoking calls on the same object (that contains the variables) throughout your project, you will have to pass that object around your project. Those variables (such as combat) will be passed alongside the object.

Now, I think what you have assumed is that you can simply say:

//Assuming the MethodProvider is passed around and not creating a new one each time
MethodProvider provider = new MethodProvider();
 
provider.combat.someMethod();

and it will know what you are talking about since Combat extends MethodProvider. Unfortunately, it doesn't quite work that way. Now, it will work that way if Combat didn't extend MethodProvider.

The reason is because there is no logistical reason for Combat to be a MethodProvider, which is what happens when you extend MethodProvider. Keep in mind that if the code you have for MethodProvider did work, that the Combat class would contain a variable named actions (which would be an Actions object), a variable named handling (which would be a Handling object), a variable named dcombat (which would be a Combat object), and a variable named data (which would be a Data object) simply because Combat extends MethodProvider. That is not what I think you are trying to do.

I can see how you could think what you did makes sense, but it is an example of one of those things that is great on paper but doesn't really translate to practice. Now, that doesn't mean that we can't get something similar to work, but it will take some feedback between you and me to get our brains synced up. I'm still trying to figure out what you think this can do and what you are trying to do. Once I have a better understanding of how this entire thing will be used, I will actually be able to get you to an answer.

Ok, so are you saying that Handling is extending MethodProvider because method provider contains a variable (actions) that is an Actions object and Handling needs to be able to use that Actions object for various reasons?

If so, then the Actions class does not need to extend MethodProvider, since it does not need anything from MethodProvider and an Actions object is created in MethodProvider. This would also mean that you would not need to create a Handling object (handling) in the MethodProvider class, since Handling is a MethodProvider object.

That would all be assuming of course that Actions does not need access to any of the variables in MethodProvider.

What if we'd initialize these variables in a different class and extend this class to use them?

Not necessarily. Remember that when you create a class, you are giving yourself the ability to create a new type of Object. If the new Object is created in a class, the class we have created the new object in has access to all of the new Object's public instance variables (as opposed to private and protected) by using that new object. When you extend a class, you are saying that the extending class is a version of the class it is extending, but with more features. So by making Actions extend MethodProvider, Actions becomes a MethodProvider object (with the added features specified in the Actions class). But, if Actions didn't extend MethodProvider, and we created a MethodProvider object in the Actions class, we have access to all of MethodProvider's instance variables (provided they are public). There is a small catch with this though. We will need 2 constructors in the Actions class. The first constructor will be a constructor that we will call from all the code other than MethodProvider, and the second will be a constructor that MethodProvider will call when it attempts to create the Actions object. The difference between the two constructors will be that a MethodProvider object SHOULD NOT be initialized in the constructor that is called from the MethodProvider class, or we have the same problem all over again (since Actions and MethodProvider will recursively create each other). Alternatively, you can have 1 constructor and a "trigger-method", which will NOT BE CALLED in the MethodProvider and will serve the sole purpose of initializing a MethodProvider object.

Tell me if that 1) makes sense and 2) goes along with what you are trying to do.

I kind of wish one of the other helpers will step in this with us since one of them might know alternatively solutions that I know nothing about.