Hello!

as i wrote in the title i'm looking for some advice with a system that i'm trying to build.

as you can see from the attached diagram i have a base class called "baseClass" and a multiple class that inherit from it, and one gamesequence manager that will manage witch that multiple sequence where i'm going to prepare the game then start the in game one....what i'm wondering is i'm looking to instantiate multiple object like player in the initialize sequence, that i would use in the inGame one...is a good way to make a reference to the object in the GameSequenceManager class then pass it with function to the other classes? this would make my objects public so i'm not lo sure that is a good idea....any help?

 

Untitled.pdf

I have some trouble understanding the question, let me just share some thoughts.

A problem with the word "Manager" is that it is very versatile, you can manage anything on behalf of something. Such classes tend to collect data and functionality, up to the point that it contains everything. To avoid that, I avoid the word "manager" as much as possible, or have a very narrow definition of what it is supposed to do. As a general rule that I use, an X-manager manages Xs, only Xs, and nothing else than Xs.

In that view, a player doesn't look like a game sequence to me, so the general rule says a game sequence manager should not manage players.

Obviously, the next problem is what to do instead. One idea would be to have a shared object that contains common information. Another question I have is whether you need all game sequences to exist at the same time? Do you need Tutorial to be present while performing inGame? If not, a solution could be to make it a sequence of function calls:

CommonData common = new CommonData();
common = doInitialize(common);
common = doTutorial(common);
common = doinGame(common);
common = doFinish(common);

which would nicely eliminate the Manager object.

7 minutes ago, Alberth said:

I have some trouble understanding the question, let me just share some thoughts.

A problem with the word "Manager" is that it is very versatile, you can manage anything on behalf of something. Such classes tend to collect data and functionality, up to the point that it contains everything. To avoid that, I avoid the word "manager" as much as possible, or have a very narrow definition of what it is supposed to do. As a general rule that I use, an X-manager manages Xs, only Xs, and nothing else than Xs.

In that view, a player doesn't look like a game sequence to me, so the general rule says a game sequence manager should not manage players.

Obviously, the next problem is what to do instead. One idea would be to have a shared object that contains common information. Another question I have is whether you need all game sequences to exist at the same time? Do you need Tutorial to be present while performing inGame? If not, a solution could be to make it a sequence of function calls:

CommonData common = new CommonData();
common = doInitialize(common);
common = doTutorial(common);
common = doinGame(common);
common = doFinish(common);

which would nicely eliminate the Manager object.

Hello!
thnk's you for your help.

About the no need of tutorial to be present in the ingame sequence is somethings that i'm still thinking of....

as you can see from my diagram, "Manager" will just execute the MainProcess based on the Enum status that would be switched on every end of process so i can get some kind of sequence, when tutorial end, just start with countdown and so on..

here "MainProcess" is Inherit function from the base class so i just need to call one function to make it work...

so you suggested me to just use Manager to manage that sequence of classes and not to get a reference of any other stuff?

i'm just learning design pattern and i'm trying to implement it..... in this way from my point of view maybe will be easy to debug....and easy to add stuff...

 

Maybe you should focus what "MainProcess" is supposed to be doing. What is its function exactly, what does it need from the environment, and what does it provide?

Ie, draw a circle in the center of a piece of paper. That's MainProcess. What should be around it? Draw a circle for each thing, and give it a name. What are the reponsibilties of all circles? how do these interact, what data gets exchanged?

Once you have a more clear picture of what your problem actually is, you can re-evaluate whether the Manager is a good solution.

maybe i got the point....
i already did something that was working all in the same class just doing a function call and make my class partial so i was able to separate everything to make it more "clean" but my teacher doesn't like it, so i'm thinking to find another way....

i'm reading really too much stuff about design pattern but i can't find out the best way that fit to this.
maybe i need more experience, or just see everything from another point by thinking in a different way..
 

This is homework? I am sorry, but I cannot help you in that case. This forum has a rule that we don't help with homework. Instead, please ask your teacher or fellow students for help.

3 hours ago, Alberth said:

This is homework? I am sorry, but I cannot help you in that case. This forum has a rule that we don't help with homework. Instead, please ask your teacher or fellow students for help.

it's not homework, i'm trying to learn as much as i can between a project in my company, i'm a noob and i want skill up to be a better programmer as soon as i can, and "my teacher" is my main programmer that's all

and, if you have an advice to witch design patter i should look in please advice me to it... thank's you!

I think you're trying things the wrong way around, I'll try to explain.

Design patterns are solutions with a name for common problems. The "gang of four" design pattern book is quite literally that.

The first question you need to answer to apply any design patterns is thus, "what is my problem?", or more realistically, "how can I split my actual problem into a set of common problems?" (any real-world problem is never a single pattern).

A second thing to consider is that the world does not only have common problems, it also has non-common problems. Any real-world problem is thus not a set of common problems where you can apply design patterns, there are also bits and pieces in it that don't fit, no matter how you turn, twist, and look at it.

I believe you can only answer "which design pattern to apply" after you have made an OO design that solves your problem. At that point you understand the problem, you can see how the classes in the solution interact, and identify the patterns and the parts that don't fit.

That means in my view, you first do a proper OO design using the SOLID principles as listed in [1] so you have a good understanding of the problem you're solving, and second, find patterns.

I always skip the second step, and instead just implement the design as I found it.

Design patterns to me are useful for communication. I can say "Adapter pattern", and you and I understand what we're talking about. This beats having to make a PDF with a collection of classes and objects to explain what I mean.

A second use of design patterns to me is that they are a source of inspiration. They solve the common problems nicely, and you can apply similar tricks to solve your real-world problems.

Trying to apply a design pattern without understanding what you're solving feels to me like picking a solution and then trying to push the problem into the shape of the solution. As an extreme example, you pick a hammer and a nail to put the painting up at the wall, even though you then find the wall is made of concrete. Will you manage to put up the painting? yep, you likely can (software is extremely flexible). Is it a nice proper job? well, I have to see the result to believe it.

A simpler path to me seems to first examine the wall, and then decide about the solution. In other words, do a OO design using SOLID, before thinking in design patterns.

[1] https://en.wikipedia.org/wiki/SOLID