I think the key phrase is particle system so most of the samples out in the wild are going to be more complex than you would think a simple demonstration should be. OOP doesn't really enter into the low level part of particle systems and C is very straight forward to convert to other languages so I wouldn't worry about that.
The trick to particles is that you want to display a LOT and as fast as possible, that colors the kinds of code you'll see since everything is optimized in one way or another.
In its simplest form a particle system for a quick splash effect would have the following elements:
- A manager both to keep track of all your systems and to give global control to all effects.
- Array of "points" where each has position, velocity, life time, display size.
- A function to create that array with a starting position and (probably) random velocities and life times.
- A function to run a simulation on that array, this probably takes a delta time since the last simulation call.
- A function to take the positions and display sizes and display then in OpenGL.
- And lastly, an overseer to stop that system from playing when all the points are dead.
Organizing the functions can be OOP at the higher levels as long as the inner loops keep to themselves in the quest for speed. Super lax pseudo code sequence below, leaving out a lot of detail and mixing and matching straight C concepts with a cheesy OOP thrown in but I hope it makes sense. The class design for this would be an entire other discussion =)
For your example, you hit a brick at world location (10,20,30). You then call the manager and ask it to start up a new points particle system at that location. The manager then asks the PointsClass to create itself at position (10,20,30). The class allocates and randomizes the life times, etc... The manager then calls all the active particle systems it controls each frame with a simulation call. Later that frame it asks the PointsClass to draw itself into a GL context. Loop until done.