The fact that your entities don't act upon each other has just ruined everything I thought I knew regarding the game logic... I thought that in the update() of the player I could do something like this (this is purely pseudo, I am actually trying to make pong...):
Before I go on I want to reiterate: just because one person does something one particular way shouldn't undo some foundational ideas you've got, and it definitely shouldn't make you switch from an approach you like. If an approach you're using works for you, go for it. In the case of object managers I personally found that the more I used them the more problems I had, so I scaled them back.
To clarify, what I try to avoid most of all is having classes impose effects on each other indirectly. I don't like having an overclass, like a manager, involved in the action-- at most, what I use in place of managers are little more than lists. It sounds like that's your approach too. In such a case, it would be complicated an unwieldy to have a single Manager object to handle objects for both a menu and a gameplay state. I think that this is a strong argument against the Manager being a global class intended for use by any and all states.
In your pseudocode example:
if self.collidesWith(Game::curState.ObjectManager.find("apple")) {player.increaseHP}
my preference would be to define the effect of Apple objects inside of the Apple class itself and then handle a collision when it takes place, instead of a big if-else chain in an Update() function which would require the game to check for every possible game event each update cycle. I would define a function in the Player class to serve as an interface for interacting with Apple or Apple-esque objects. So when a collision takes place you might have something like player.CollidesWith([instance of Apple class]). Then the player object would handle the Apple-collision, with something like this.IncreaseHP([instance of Apple class]), where the IncreaseHP function accepts the Apple object as an argument to determine how much of an HP increase the player will get. It's really the same as what you wrote above, except that it doesn't query the ObjectManager.
Involving an object manager class in the interaction doesn't seem necessary to me, and using one (to my mind) makes the intended interactions between Player and Apple less clear while encouraging a less flexible interface through which Player objects interact with other objects. This (again, for me) makes the code less intuitive and therefore harder for me to work with. The object manager style classes, in my projects, exist more or less so that I can iterate through all of the objects in a scene to update them. They don't reach into the objects they manage for any purpose, and those objects usually only reach back to the manager to remove themselves when appropriate.
This happens all the time.. I think I finally manage to do something right then I realize that it's all wrong. My idea was to make the Game class a singleton because there can only be one game.. and somehow the entities must know about each other, so the entities can just include the Game header... Then I thought the Game class would hold a reference to the current state the game is in. And the state
has an objectManager that holds all the objects in the current state.
There's not a "right" way to do things, in the sense this quote suggests. You're not wrong, and all of this seems standard enough. For Pong, a singleton-style Game class should be fine, and it's very common for the game's current state to be stored as a reference in another class (including Game, if that fits your design). And a state can definitely have an object manager if that's what you decide to do. The biggest question that you should ask yourself when deciding on an approach to use is: does this approach do what I need? If so, it's not going to be "wrong". It might be less than ideal from a maintainablity standpoint, a programming theory standpoint, a performance standpoint, or any number of other considerations.
Ultimately though these considerations are secondary to the "does it work?" criterion. If it works, it's "right" enough. All the rest is asking a question like "could it work better?".
