... i had thought that it would be ok to make a for() loop and cycle through the entities and only apply the logic based on the individual objects relevance to the currently running instance of the class, but i'm guessing what you're suggesting is i have some kind of external class that governs logic and sweeps through my vector and applies logic externally, instead of the entities being in control of their own logic?
It really depends on your definition of "own logic".
A simple example is collision. Some beginners will handle collision by getting each object to iterate through the object list, testing for collision. This heavily couples the object's logic to the list of other objects in the game. For example, you may end up littering your code with tests for objects that are "inactive" or otherwise uninteresting. If you add a new object type - for example a "trigger" object which can be used to activate a cut scene when a character enters a certain area, now you might have several loops you need to inspect to ensure that, for example, you Ogre doesn't choose the trigger as its next meal.
Advanced games will totally separate collision from the entities involved, usually via a physics library. An entity can own certain physics bodies, and the appropriate callback mechanism can be used to tie game logic to physics events such as collision. A middle ground for a small project is to have the calling code iterate through the list and notify the objects when a collision occurs.
It also depends on the scope of your game. A pong game doesn't warrant this complexity.