• Create Account

### #ActualSolarChronus

Posted 31 October 2012 - 06:48 PM

After reading up on MVC as you suggested I look into, I have totally re-designed the combat ui code. I grouped all the major UI elements into frames so they act as my views, created a an overarching HUD file that acts as the controller and let the combat arena scene act as the model. Combined with events I can easily change the hud elements without impacting the way the user interacts with the scene or re-tooling the model. Thanks for the suggestion!

As for those public data members, whoops, that was more a typo then wanting them exposed! I do have another question though on the best way to design out my subsystem installation code. Right now my design would work like this(pseudo-code):

public void InstallSubsystem(Subsystem subsystem)
{
switch(subsystem.Type)
{
case SubsystemType.EngineCore:
InstallEngineCore((EngineCore)subsystem);
break;
}
}

private void InstallEngineCore(EngineCore engineCore)
{
//Stuff associated with installing/replacing a subsystem here.
}


My one gripe with this is the use of the switch statement. I wanted to encapsulate the installation functionality so that the only thing that needs to be called is InstallSubsystem(...) when a subsystem is to be installed/replaced. I could get rid of that function and expose the individual methods for installing each subsystem but felt like that is just too much exposure. I am butting up against the limits of my knowledge on this one, and wonder if the switch is really the best way to go or would there be an alternative?

### #1SolarChronus

Posted 31 October 2012 - 06:46 PM

After reading up on MVC as you suggested I look into, I have totally re-designed the combat ui code. I grouped all the major UI elements into frames so they act as my views, created a an overarching HUD file that acts as the controller and let the combat arena scene act as the model. Combined with events I can easily change the hud elements without impacting the way the user interacts with the scene or re-tooling the model. Thanks for the suggestion!

As for those public data members, whoops, that was more a typo then wanting them exposed! I do have another question though on the best way to design out my subsystem installation code. Right now my design would work like this(pseudo-code):

public void InstallSubsystem(Subsystem subsystem)
{
switch(subsystem.Type)
{
case SubsystemType.EngineCore:
InstallEngineCore((EngineCore)subsystem);
break;
}
}

private void InstallEngineCore(EngineCore engineCore)
{
//Stuff associated with installing/replacing a subsystem here.
}


My one gripe with this is the use of the switch statement. I wanted to encapsulate the installation functionality so that the only thing that needs to be called is InstallSubsystem(...) when a subsystem is to be installed/replaced. I could get rid of that function and expose the individual methods for installing each subsystem, but feel like that is just too much exposure. I am butting up against the limits of my knowledge on this one, and wonder if the switch is really the best way to go or would there be an alternative?

PARTNERS