You are using something like the Entity pattern but you are finding you need greater granularity. Not all of your game objects are physical objects which need to have all the associated logic. Instead some objects only need to be updated frequently but can otherwise be left alone. For instance, you want to add fading score bubbles, particle effects, or other flourishes to your game.

The Active Entity pattern expands on the Entity pattern by decoupling the concept of an updatable entity from that of a physical entity. Since not all objects which need to be regularly updated, that is animated, need to know when they intersect with other objects it makes sense to separate the entity interface into two distinct types. This page covers one type, the Active Entity.

• Entity
• Abstract Entity
• EntityGroup
• Tangible Entity

public interface ActiveEntity {
 
    public void init(Game game);
    public void update(Game game, Graphics g);
}

Adopting this pattern carries several advantages. First, the added flexibility allows you to implement cheap classes which can animate or poll for events without requiring them to implement a set of methods which they will never use thus reducing the amount of boilerplate code in your game. Second, by adopting this pattern you can better separate the different concerns in your game. You can now maintain active entities separately from physical ones which means you will end up spending less time checking for no-op intersections and performing no-op updates.

Obviously this pattern adds an additional level of complexity to your game. Whereas under the Entity pattern everything was under a common interface you now have to manage two parallel interfaces. Oftentimes an object will be both an active and tangible entity and in those cases you will need to do some additional bookkeeping to ensure that things run as smoothly as before.