Best practices, software architecture question

Question

I'd like to offer a challenge to everyone in good software architectural design principles. Here is a mocked up version of some code that I've been working with, grossly over-simplified for this example. Take a look at the following classes and see if you can determine what the parentComponent will be for the JOptionPane that is displayed in the HardDriveController's constructor:
public abstract class Controller {
    private JFrame parentFrame = null;
    public void setParentFrame(JFrame parent) {
        this.parentFrame = parent;
    public JFrame getParentFrame() {
        return parentFrame;
public class MyGUI extends JFrame {
    private CPUController cpuController = null;
    public MyGUI() {
        setSize(300, 300);
        setVisible(true);
        cpuController = new CPUController();
        cpuController.setParentFrame(this);
    public static void main(String [] args) {
        new MyGUI();
public class CPUController extends Controller {
    private RAMController ramController = null;
    public CPUController() {
        ramController = new RAMController();
public class RAMController extends Controller {
    private BusController busController = null;
    public RAMController() {
        busController = new BusController();
public class BusController extends Controller {
    private HardDriveController hardDriveController = null;
    public BusController() {
        hardDriveController = new HardDriveController();
public class HardDriveController extends Controller {
    public HardDriveController() {
        JOptionPane.showMessageDialog(
                getParentFrame(), "Hey! We're inside the HardDriveController!");
}Did you figure it out? If you said the parentComponent will be null, then you are correct. The logic behind the code had intended to set the parentComponent to refer to MyGUI, but of course, the code does not behave as expected. Now this seems simple enough, but the legacy code I'm working with is full of many examples like this. Notice how MyGUI creates an instance of CPUController which creates an instance of RAMController, which creates an instance of BusController, etc...In some cases, I see a "Controller" class that is 8 or 9 "levels" deep with respect to one controller creating another, creating another, etc.
Let's say that I want the JOptionPane in the above example to have its parentComponent refer to the instance of MyGUI. The following code is one means of passing the reference down to the HardDriveController, while still using the getParentFrame() method in HardDriveController:
public class MyGUI extends JFrame {
    private CPUController cpuController = null;
    public MyGUI() {
        setSize(300, 300);
        setVisible(true);
        cpuController = new CPUController(this);
    public static void main(String [] args) {
        new MyGUI();
public class CPUController extends Controller {
    private RAMController ramController = null;
    public CPUController(JFrame frame) {
        setParentFrame(frame);
        ramController = new RAMController(frame);
public class RAMController extends Controller {
    private BusController busController = null;
    public RAMController(JFrame frame) {
        setParentFrame(frame);
        busController = new BusController(frame);
public class BusController extends Controller {
    private HardDriveController hardDriveController = null;
    public BusController(JFrame frame) {
        setParentFrame(frame);
        hardDriveController = new HardDriveController(frame);
public class HardDriveController extends Controller {
    public HardDriveController(JFrame frame) {
        setParentFrame(frame);
        JOptionPane.showMessageDialog(
                getParentFrame(), "Hey! We're inside the HardDriveController!");
}Note that the reason I'm calling the Controller class's setParentFrame() method in each extended class's constructor is that I want to ensure that any call to getParentFrame() in these classes will return a reference to MyGUI, and not null.
After this long description, I want to ask all you Java gurus the following question: What is the best means of offering the JOptionPane a reference to MyGUI? My solution passes a JFrame reference all the way down from the CPUController to the HardDriveController. Is this an "acceptable" solution, or is there a more elegant means of getting a reference to MyGUI to the JOptionPane (for example, modifying the MyGUI class to follow the singleton pattern)? Thanks for your input. 

Answer 1

Proflux, One thing I failed to mention is that this is a very old codebase and the likelihood of the object graph being reworked is slim to none. I agree with you 100% that the dependency doesn't feel right. But I have to live with it. I mentioned the idea of using a singleton pattern. Here's a mock up of how that would look:
public class FrameRetriever {
    private static FrameRetriever instance = null;
    private HashTable frameHash = new HashTable();
    private FrameRetriever() {
    public static getInstance() {
        if(instance == null) {
            instance = new FrameRetriever();
        return instance;
    public void addFrame(JFrame frame)
        frameHash.put(frame.getTitle(), frame);
    public JFrame getFrame(String frameTitle)
        return (JFrame) frameHash.get(frameTitle);
public class MyGUI extends JFrame {
    private CPUController cpuController = null;
    public MyGUI() {
        setTitle("Test GUI");
        setSize(300, 300);
        setVisible(true);
        FrameRetriever.getInstance().addFrame(this);
        cpuController = new CPUController();
    public static void main(String [] args) {
        new MyGUI();
public class HardDriveController extends Controller {
    public HardDriveController() {
        JFrame parentFrame = FrameRetriever.getInstance().getFrame("Test GUI");
        JOptionPane.showMessageDialog(
                parentFrame, "Hey! We're inside the HardDriveController!");
}My only concern with this solution is that it couples the HardDriveController to MyGUI because we need to know the frame's title in order to get the frame instance. But at the same time, I won't have to add constructor arguments to any "in between" classes for the sole purpose of passing a reference down the object graph. Any thoughts?