"Bridging" (Connecting) methods between distant classes

Question

Lets suppose I have Planet and Star classes and GameLogic class in the following way

//Planet.java
package Game;

class Planet //invisible outside of package
{
   public String getType() {return "Im a Planet";}
}

.

//Star.java
package Game;

class Star //invisible outside of package
{
   public String getType() {return "Im a Star";}
}

.

//GameLogic.java
package Game;

public class GameLogic //notice the PUBLIC keyword
{
   //arrayList of stars
   //arrayList of planets

   //a ton of methods for the logic of the game itself
}

These all belong to the Game package which treats only the whole logic of the game with no input/output.

Then, in a different package called UI I have the Text class (UI.Text) which controls user input, prints output and has direct access to the GameLogic because the game can only be played by creating an instance of the GameLogic class.

//Text.java
package UI;
import Game.*;

public class Text
{
   //some control vars

   //MAIN method
   //input and output methods
   //bla bla bla
}

So the issue is: The game will be instantiated in Text.java by creating a GameLogic instance. Given this, if i wanted to output the getType() functions from Star and Planet, I'd have to complete the "road" that connects Text with Planet/Star in the following way

//GameLogic.java
package Game;

public class GameLogic
{
   //same as before

   public String getPlanetType(int n) {return planetArrayList.get(n).getType();}
   public String getStarType(int n) {return starArrayList.get(n).getType();}
}

In short, the getType() methods already exist in a "too-far-away" class, so it forces me to create these simple, yet repetitive, "bridge" methods to connect both ends.

TL-DR version:

class A has getType()

class B has array of A

class C needs to access getType() from array of A in B

I believe this is a very inefficient and time consuming method and that there is a better alternative (possibly involving Interfaces?), so if anyone could provide me with some help, I'd be very grateful.

Thank you

read about *The Law of Demeter*, how you avoid breaking it, is on a case by case basis, but my **opinion** is you should not be returning they type like this but the relevant object directly. — , Apr 18 '16 at 13:39
Why are Star and Planet not public if the Text class needs them? In other words, if A needs information about C, it shouldn't go through B, it should just have access to C directly. This is the "Law of Demeter". — Chris Wohlert, Apr 18 '16 at 13:41
@ChrisWohlert This is for a college project and it's required to separate UI and game logic into separate packages, i assume to teach us about making our code as generic and adaptable as possible, so different packages can work with it. Although not required, i chose to only make one single class public, so by importing the Game package you could only instantiate the game itself through one single class. — jagnelo, Apr 18 '16 at 18:14
@joaoA, My suggestion still keeps things in their rightful packages. When you design a package, you must consider its API. It seems you have considered this, but concluded that only one class may be public, this puts a lot of responsibility on that class. This is not necessarily the correct result though. To reiterate, if you want to bridge distant classes; Close the gap. If you don't want to take my word for it, you can instead research terms like "Context independence", "Law of Demeter", "Encapsulation" and "Information hiding". I'm betting this is what your professor is after ;) — Chris Wohlert, Apr 19 '16 at 14:24

GhostCat · Accepted Answer · 2016-04-18T14:02:21.557

Don't believe anything regarding performance.

The only thing that matters is reality.

And in reality, the JIT will most often turn your attempts to micro-optimize upside down.

Meaning: don't worry about performance (too much) until you see real issues. If you have issues, start measuring instead of making assumptions.

Instead: focus on good, clean designs; follow the SOLID principles; and write clean, readable, maintainable code. That will pay of a hundred times more than worrying about such subtleties.

( and just to give you an example: a method getType() that returns a String already looks like a broken design. Considered using enums? Or even more strange: do you realize that alone by using different classes, your objects have different types?)

And if you still think you should look into performance, than start by reading about the JIT, how it works, what it does, and so on.

I appreciate the answer a ton, and shall indeed look more into the SOLID concept. The getType() function returning a String was just a vague example, by the way, this is for a college project in java. I already have quite a bit of knowledge and flexibility in OOP, though im trying to fill in some gaps in said knowledge. It's both funny and sad how stackoverflow users are better teachers than the ones whose salaries i help pay. Thank you! — jagnelo, Apr 18 '16 at 18:11

"Bridging" (Connecting) methods between distant classes

1 Answers1