Jump to content
  • Advertisement
Sign in to follow this  
SolarChronus

Inheritance, Interfaces, and code duplication

This topic is 2030 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Advertisement
Another option is one class that has multiple CreateBlahBlahBlah() functions and you pass the constructor an enum or something similar to select which one is called when the Create() function is called. Yet another would be have your Create() function identify what kind of encounter type is being created from the XML and call the appropriate create implementation automatically without the caller needing to know exactly what kind of encounter is encoded inside the XML.

Share this post


Link to post
Share on other sites

It seems to me like you'd want to move your mission creation to an entirely separate factory class that knows how to parse the XML data for each individual mission type and construct them by passing the relevant data directly to their constructors. That way missions know nothing about XML or how they came to be, just that they now exist and have appropriate data.

 

This will also allow you to remove the Create() function from your IEncounter interface, which doesn't really seem to belong there. I inferred that "encounters" handle mission sequencing from the GetNext() method, but also having them create the missions gives them multiple responsibilities and violates SRP.

Share this post


Link to post
Share on other sites

@Zipster I think some confusion is a product of bad class naming on my part. The MissionEncounter class would be considered the factory for loading all the mission xml data into a list of missions and then handing one out when requested. There is an actual Mission class which only houses the data for that mission, title text, description, messages, choices, etc. Same with the shop, loot, and ship classes.

Share this post


Link to post
Share on other sites

I would probably do something along the lines of this:

 

public class Encounter : IEncounter
{
    private RandomizedList<Encounterable> list = new RandomizedList<Encounterable>();
    private EncounterStrategy strategy;

    public Encounter(EncounterStrategy strategy)
    {
        string[] files = Reader.GetXmlFiles(strategy.getPath());
        this.strategy = strategy;
        Create(files, list);
        list.Shuffle();
    }

    public Encounterable GetNext()
    {
        return list.Next();
    }

    private void Create(string[] files, RandomizedList<Encounterable> list)
    {
        for (int i = 0; i < files.Length; i++)
        {
            //...use XML to retrieve Encounter(Mission in this case) specific information
            //the strategy creates the proper Encounterable.
            //add Encounterable to list.
        }
    }
}


public interface EncounterStrategy
{
    string getPath();
    //other methods required to create encounterable.
}

 

 

This way all of the unique functionality is in one place (MissionEncounterStrategy, LootEncounterStrategy, etc.) instead of forcing you to inherit and keep overriding create methods.

 

EDIT:  lots of little code errors.

Edited by SeraphLance

Share this post


Link to post
Share on other sites

@SeraphLance

 

Interesting concept there, but I am left wondering something. Each encounterable will have differing data. Missions (title, mission text, choices, and outcomes) differs from a Shop encounterable (dealer name, type of items they sell, stock). So the lines of code in the create method for the XML portion would be drastically different as they are targeting different elements and attributes. 

 

I'm leaning towards SiCranes response, about having the Create method choose the XML method to use to grab the information out of the file. I'm just worried I'll end up creating smelly switch statements. I understand if used properly (once and only once for a certain procedure) they are fine, but I typically over use them in some areas and they've been a pain in the butt to modify when I've had major additions, and the fact I haven't been able to grasp the polymorphic alternative to switch statements. Most examples are so simple I have a hard time translating how to apply them to my code.

Share this post


Link to post
Share on other sites

@SeraphLance

 

Interesting concept there, but I am left wondering something. Each encounterable will have differing data. Missions (title, mission text, choices, and outcomes) differs from a Shop encounterable (dealer name, type of items they sell, stock). So the lines of code in the create method for the XML portion would be drastically different as they are targeting different elements and attributes. 

 

I'm leaning towards SiCranes response, about having the Create method choose the XML method to use to grab the information out of the file. I'm just worried I'll end up creating smelly switch statements. I understand if used properly (once and only once for a certain procedure) they are fine, but I typically over use them in some areas and they've been a pain in the butt to modify when I've had major additions, and the fact I haven't been able to grasp the polymorphic alternative to switch statements. Most examples are so simple I have a hard time translating how to apply them to my code.

 

That's what the strategy is for.  The strategy implementation stores a path and knows how to read the files from that path to create encounterables.  One "could" argue that it's a violation of the SRP to do both, but I'd say they're sufficiently connected tasks.  The strategy pattern basically is the polymorphic alternative to switch statements.

 

It's worth noting that the whole strategy.getPath() thing is kind of stupid, but I put it in there as a sort of minimum-modification example.  Really, the create function in this case would just have the strategy handle all that.

Share this post


Link to post
Share on other sites
@Serpah.

Aha! I see what you mean now. Ill try that out when Im back at my computer.

As for breaking SRP, I have a static xml class that retrieves data for me in all the major types and allows casting to custom types via some simple method invokes. Im not actually writing xml reader code in the create method, so SRP should be mostly satified.

Share this post


Link to post
Share on other sites

If I understand the code correctly, I am seeing 2 problems here. The Encounter class does too many things and Mission is only vaguely defined.

 

Encounter currently handles Mission creation and Mission enumeration.

 

You are saying, there will be different kind of Missions with different data. Would it be possible to make Mission a base class and extend from there different Mission types? Maybe it would even be possible to model all the different scenarious by making Mission a container for "MissionObjectives".

 

Then you can move the creation logic out of the Encounter class and create a list of Mission objects which are filled by factories based on the xml supplied.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!