I guess, I ignored the rule "don't have classes that tries to do too much".
Tahts an example of a terrible constructor.
The "StateMachine" is a class which manges diffrent game-states and the conditions to change from one state to an other.
GameState gameState, // Container of the current state, the last state and the events
WorldEvents worldEvents, // Helper to add or remove items into the world
ResourceLoader resourceLoader, // Language-Helper to get a translatet text
GameSettings gameSettings, // Options of the game
List<CommandBase> commands, // All classes that gives the opurtunity fot user-interaction
List<AiBase> aiAlgorithms, // Logic of AI
List<WorkerBase> helpers, // Alle other helpers
ServerCallbackSynchroniser serverCallbackSynchroniser, // Helper class so sync repsonses from the server to the game-Thread
GameLauncher gameLauncher) // Helper class to start a battle
Why the hell is "AI-Algorithms" and all the other stuff needed in a simple class like "StateMachine" ? Why not just passing the "GameState" instance?
That's what I thought now by myself.
I have to tell, that this is my first big game project. It started small and grown. I did some code refactoring but I never cared about splitting classes. So the design get worse and worse. Some weeks ago I started reading "Clean Code" of "Robert C Martin" and I noticed theres something bad, but I had no idea what's the solution.
I very like all of your advices. If I follow them there's a chance.
Thanks a lot!