how to access main class objects in other classes without a constructor in a processing/java eclipse project?

Question

I cant seem to find an answer on the internet anywhere.

So I have a processing project in Eclipse

I want to be able to access objects in my "main" class that extends PApplet in another class without having to pass them through the constructor. I am not the most experienced programmer so my terminology might be off but hopefully this example clarifies what I am trying to do.

so for

---

public class Main Extends PApplet{

    //Example Class to access objects from main
    Interaction interaction;   

    //Example Objects I want
    boolean someObject;

    void setup(){        
        someObject = true;
        Interaction = new Interaction();  
    }

    void draw(){
    }   
}

public class Interaction{

    PApplet p;

    public Interaction(PApplet parent){
        p = parent;
    }

    public void mousePressed(){
        if(someObject){
            //do something
        }   
    }
}  

---

so I know I could pass that object into the constructor of Interaction like

PApplet p;
boolean o;

public Interaction (PApplet parent, boolean SomeObject){
    p = parent;
    o = someObject;
}

but this gets a little crazy in an example like this where I just want to hold all of my mouse and keyboard interaction in its own class because its getting huge, but I have run into the need to this time and time again and cant seem to figure it out.

Answer 1

What you are describing is called a getter method.

You can add a getter method to your Main, but first read this -> http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.html

Here is the example.

public class Main Extends PApplet {

    ...

    public boolean getSomeObject ( )
    {
        return someObject;
    }
}

public class Interaction {

   PApplet p;

   public Interaction(PApplet parent){
      p = parent;
   }

   public void mousePressed() {

       if( p.getSomeObject( ) ) {
           //do something
       }

   }
}

BTW, boolean is not an Object in Java, Boolean is.

EDIT After your comment I DO understand what you need.

You need to create an interface and pass this interface to Interaction constructor.

This interface should provide all the method that your Interaction needs. If it needs an access to PApplet, then that's what your interface should provide.

With this in mind, here is a new hierarchy:

public interface IInteractionContext
{
  boolean getSomeObject( );
}

public class Main
  extends PApplet
  implements IInteractionContext
{
  @Override
  public boolean getSomeObject ( )
  {
    return someObject;
  }

  ...
}

public class Main Extends PApplet {

    ...

    public boolean getSomeObject ( )
    {
        return someObject;
    }
}

public class Interaction {

   final IInteractionContext ctx;

   public Interaction(IInteractionContext ctx)
   {
      this.ctx = ctx;
   }

   public void mousePressed() {

       if( ctx.getSomeObject( ) )
       {
           //do something
       }

   }
}

With these changes, Interaction could care less if ctx is Main, PApplet or Unicorn. Its constructor requests the expected behavior and your implementation of Main provides this behavior at runtime.

In any case read the javaworld article and related articles. Also, read articles about Dependency Injection

Answer 2

An applet is basically a top level container for an application that provides a context for user interaction GUI/Display and input (mouse clicks, keyboard).

In a well designed application, your business logic should be encapsulated in one or more classes, and you would call methods on this based on external input and then perhaps query it for information for output to the GUI. This is very much a generalization BTW.

The top level container (in this case, the Applet) should only be concerned with instantiating your business objects, capturing user input, calling methods on the business objects and then updating the GUI based on the state of the business objects.

I'm guessing that you feel compelled to wrap all of your interaction code into a class to keep it clear for the business logic. If this is the case, it is the business logic that should be encapsulated, not spread through the Applet class. This would allow you to easily transfer your business object to a desktop application or even run it without a GUI at all.