class MapManager
{
public:
static MapManager& getMapManagerInstance(); // returns static object of MapManager
void loadMap(filename)
{
unloadMap(); unloads first
if(isMapFileValid(filename))
//loads map to currentmap vector
}
void unloadMap()
{
//unload map when the game ends or he goes to main menu
}
std::vector<std::string> getmapnames();
bool isMapFileValid(filename);
void addMap(filename)
{
mapnames.emplace_back(filename);
}
private:
std::ifstream fopener;
std::vector<std::string> mapnames;
std::vector<vector2> currentmap;
}
int main()
{
MapManager::getMapManagerInstance().addMap("map1.txt");
MapManager::getMapManagerInstance().addMap("map2.txt");
MapManager::getMapManagerInstance().addMap("map3.txt");
std::vector<std::string> names = MapManager::getMapManagerInstance().getmapnames();
// list the map names
std::string pickedmap;
//user picks map 1
MapManager::getMapManagerInstance().load(pickedmap);
//user changes his mind and want to pick map 2
MapManager::getMapManagerInstance().load(pickedmap);
}
what do you guys prefer here? or if both design sucks then what should i do?
I like the idea of having a Map as a separate class from the Manager. That way, you encapsulate operations on the map separately from managing the collection of maps.
In your first example, however, I would put the std::vector inside the Manager. Since the Manager is ostensibly managing the maps, then it should own the vector that contains them.
There are a whole lot of things I don't know (like what a vector2 is, why a std::vector<vector2> needs to be returned to the used when a map is loaded [rather than a Map reference perhaps], etc.), so I can't comment on whether the overall design makes sense, but separating map functions from the management functions is probably a good idea.
The better question might be "what are the purpose and responsibility of the Manager class?" When I glanced through your code, my assumption was that the class was responsible for managing a set of Map objects and presenting the correct object when requested. That may not be what you intended. You may have wanted the Map Manager to simply load a Map when needed, in which case, the class name may be a bit misleading IMO.
When you properly define the scope of the class, what objects it contains will become obvious. Careful naming of the classes will help, especially when others are invited into the design/review process.
So, to answer your question, it depends. What are you trying to do with it?
if it were a set of map objects with some sort of selector, as doug4 expected, it could make sense, as long as it's not a singleton. If it's just a collection of maps, there's std::vector for that.
in the first design:
i made my MapManager to be like a file reader and checker. because the matrix of map is stored in a txtfile, and the loader of the txtfile's content is MapManager's role.
in the 2nd design:
still the same role but in addition it holds all the mapnames and std::vector<vector2> currentmap; which holds the current map to be rendered on the screen.