Magic Bullet?
It is, of course, not a magic bullet that solve every problem with ease, but it is a powerful tool for making potentially complicated things look somewhat simpler. Powerful tools, however, can also cause damage when used without care, or without sufficient understanding. All approaches to programming can only deliver correct results if they maintain the integrity of the information stored within the software system. (By this we mean that we always assign a consistent meaning to data, and every manipulation of the data maintains a consistent interpretation.) OO programming often helps to protect information integrity, but it also provides subtle paths to damaging integrity in ways that can be very difficult to track down even if you are using the advanced tools and techniques of the professional software engineer. It is therefore particularly important to avoid introducing defects into the software as far as reasonably possible, because they can be harder to find and eliminate once they are there.
The inexperienced do sometimes underestimate the degree of skill and background knowledge required to build complex software using OO methods, particularly as very experienced engineers can exploit OO methods to take what look like shortcuts to the less experienced: the conceptual abstractions provided by this approach allow the expert to keep more understanding of the system safely in their head at any one time. These types of shortcuts, however, only prove to be shortcuts for those who have built the required mental skills by having thoroughly explored the long ways round.
Having said all that, the level of intrinsic complexity of generative art programs is often less than one might think given the apparent complexity of the images. The warnings given above are sound, but since we are not attempting to scale the high peaks of software construction we can usually take a more relaxed attitude to the normal protective measures - often without serious harm ensuing.
We can get a better handle on these abstract ideas by looking at a specific example.
Consider the possibility of using Processing to simulate the flocking behaviour of birds, for example starlings, which at certain times of year collect in enormous "murmurations" before roosting, creating complex patterns in the sky as they manoeuvre around trying to avoid collisions while staying together.
We believe (for the sake of this example - a gross oversimplification!) that each bird follows a relatively simple set of rules: follow the bird in front - but do not get closer than, say, three body lengths. Avoid collisions with the birds to left, right, up and down, by staying three wing-spans apart. If you have no bird in front move randomly. There will, of course, also be a slight delay in responding to movements of the neighbouring birds.
The OO approach considers each of the birds in the flock to be instances of a class, where each instance has a unique identity and internal state (the unique attributes of a bird comprising in this case the position and velocity of the bird in space). Every instance, however, uses the same algorithms to respond to a limited number of well-defined stimuli from the external world. (The stimuli might be: "bird in front changing direction", "bird-to-left too-close" and so on.)
We are dealing with a sufficiently simple situation that we might be tempted, probably with justification, to jump straight to prototyping an implementation using the OO programming tools in Processing. There is, for example, a class structure. We can declare the position and velocity variables to be attributes of every object in the class, and provide methods by which an object instance will respond to stimuli coming from other objects (e.g. "too close!") To start everything off we might create a few thousand instances of birds with random positions and velocities. Then we see what happens when we allow all the objects to step forward through time. (There are lots of technical details elided here.)
A non-object oriented programming approach - probably easier to start with for the novice - might store all the birds' x-positions in one array, their y-positions in another, their height above ground in another, velocity and direction in other arrays and so on. The algorithms would iterate over all the elements of these arrays. In practice, all the same calculations would be performed. The computer would not know any real difference. However, we as the implementers of the program understand it is a different way.