Based on the quote you gave, I can only surmise that he was referring to code that made decisions in a very "linear" pattern like (for example):
Let's say I'm creating a program that both controls a robot AND keeps track of its activities. The robot can move, cook and clean. (Let's keep it simple). Each time the robot performs one of these activities, the program will react differently based on the activity being performed.
For example, if the robot is walking, the program will display the battery life, number of steps taken, etc...
What I could do is create a list of if-else statements that test the robot's current activity and activates the required response.
The problem with this line-by-line code decision style is that:
a) It makes your code messy, eventually. You'd have to keep adding if-else statements that would take up an enormous chunk of code space in your source. Makes debugging harder and the code very difficult to read and error prone.
b) It's hard to extend. What if you wanted the program to do multiple things when it observed that the robot was walking? For example, if the robot walked, then the program would then have to display the status information, update the owner's smartphone to indicate what is being done, deactivate the security alarm in the owner's house so that it doesn't go off, etc...?
Because we're using if-else statements, we'd have to locate the correct if-else block, add in the desired code (which would potentially involve adding more if-else blocks) and at the same time make the whole program more convoluted.
The C++ coding pattern to solve this problem would be the "Observer Design Pattern":
Basically, you create 2 classes. One models the robot class and its activities (Walk, Cook and Clean would be methods). It would also contain a list of "Observers" - more on that in a moment - which it will Notify
when any of its activities are called.
The second class is the Observer that in its simplest form contains an Update method. This update method would contain the code for the specific task.
The beauty of this design pattern is that you can create as many Observers as you'd like for each of the robot's methods. You add them to the Robot's list of Observers and that's all.
When the Robot's Walk method is called, that method will notify all of its Observers in the list and each Observer will react accordingly.
Doing it this way using OOP principles makes the program more easy to understand, shorter and provides room for extensibility.
That's my take on it. If you read the link I gave you (I found it on the web a while back) it does a good job of quickly giving you an example of an Observer Design pattern.
Hope that helps,