When you read the blog post you linked to, then you will see that "being a Manager if by another name" is exactly what it wants you do to. It's general consensus in software development that global variables are evil, and the only alternative is that any data is held by other data.

The problem with a class named FoobarManager is that the word "Manager" doesn't tell you what the class actually does. For example:

• When it controls the game mechanics of the foobars, you can name it FoobarController.
• When it instantiates foobars but then delegates control to something else, it's a FoobarFactory or FoobarBuilder.
• When it draws the foobars to the screen, it's a FoobarRenderer.
• When it listens to events generated by foobars, it's a FoobarEventHandler.
• When it waits for something to happen with the foobars, it's a FoobarObserver.
• When it's just a dumb data holder for a collection of foobars without any logic at all, you just name it Foobars.

You could name any of these classes "Manager". But then it could perform any of these functionalities. And when you later realize that you need another of the above functionalities, you will also integrate that into the FoobarManager. So you will end up with a god object which will breaks the Separation of Concerns principle (every class should do exactly one thing).

When you read the blog post you linked to in the comments, then you will see that "being a Manager if by another name" is exactly what it wants you do to. It's general consensus in software development that global variables are evil, and the only alternative is that any data is held by other data.

The problem with a class named FoobarManager is that the word "Manager" doesn't tell you what the class actually does. For example:

• When it controls the game mechanics of the foobars, you can name it FoobarController.
• When it instantiates foobars but then delegates control to something else, it's a FoobarFactory or FoobarBuilder.
• When it draws the foobars to the screen, it's a FoobarRenderer.
• When it listens to events generated by foobars, it's a FoobarEventHandler.
• When it waits for something to happen with the foobars, it's a FoobarObserver.
• When it's just a dumb data holder for a collection of foobars without any logic at all, you just name it Foobars.

You could name any of these classes "Manager". But then it could perform any of these functionalities. And when you later realize that you need another of the above functionalities, you will also integrate that into the FoobarManager. So you will end up with a God Object which breaks the Separation of Concerns principle (every class should do exactly one thing).

When you read the blog post you linked to, then you will see that "being a Manager if by another name" is exactly what it wants you do to. It's general consensus in software development that global variables are evil, and the only alternative is that any data is held by other data.

The problem with a class named FoobarManager is that the word "Manager" doesn't tell you what the class actually does.

When it controls the game mechanics of the foobars, you can name it FoobarController. When it instantiates foobars but then delegates control to something else, it's a FoobarFactory or FoobarBuilder. When it draws the foobars to the screen, it's a FooobarRenderer. When it's just a dumb data holder for a collection of foobars without any logic at all, you just name it Foobars.

When you read the blog post you linked to, then you will see that "being a Manager if by another name" is exactly what it wants you do to. It's general consensus in software development that global variables are evil, and the only alternative is that any data is held by other data.

The problem with a class named FoobarManager is that the word "Manager" doesn't tell you what the class actually does. For example:

• When it controls the game mechanics of the foobars, you can name it FoobarController.
• When it instantiates foobars but then delegates control to something else, it's a FoobarFactory or FoobarBuilder.
• When it draws the foobars to the screen, it's a FoobarRenderer.
• When it listens to events generated by foobars, it's a FoobarEventHandler.
• When it waits for something to happen with the foobars, it's a FoobarObserver.
• When it's just a dumb data holder for a collection of foobars without any logic at all, you just name it Foobars.

You could name any of these classes "Manager". But then it could perform any of these functionalities. And when you later realize that you need another of the above functionalities, you will also integrate that into the FoobarManager. So you will end up with a god object which will breaks the Separation of Concerns principle (every class should do exactly one thing).