I think to understand this question, you need to understand what an abstraction is. (I'm too lazy to find a formal definition, so I'm sure I'm about to get dinged, but here goes...) An abstraction is when you take a complex subject, or entity and hide most of its details while exposing the functionality that still defines the essence of that object.
I believe the example the book gave you was a house. If you take a very detailed look at the house, you'll see that it's made of boards, nails, windows, doors... But a cartoon drawing of a house next to a photograph is still a house, even though it is missing many of those details.
Same thing with software. Whenever you program, just like the book advises, you need to think about your software as layers. A given program can easily have well over a hundred layers. At the bottom, you might have assembly instructions which run on a CPU, at a higher level these instructions might be combined to form disk I/O routines, at a yet a higher level, you don't need to work with Disk I/O directly because you can use Windows functions to simply Open/Read/Write/Seek/Close a file. These are all abstractions even before you get to your own application code.
Within your code, the abstraction layers continue. You might have lower-level string/network/data manipulation routines. At a higher level you might combine those routines into subsystems that define user management, UI layer, database access. Yet another layer these subsystems might be combined into server components that come together to become part of a larger enterprise system.
The key to each of these abstraction layers is that each one hides the details exposed by the previous layer(s) and presents a very clean interface to be consumed by the next layer up. To open a file, you shouldn't have to know how to write individual sectors or what hardware interrupts to process. But if you start travel down the abstraction layer chain, you will definitely be able to trace from Write() function call, all the way down to the exact instruction that is sent to the hard drive controller.
What the author is telling you to do is when you define a class or a function, think about what layer you are one. If you have a class that is managing subsystems and user objects, the same class should not be performing low level string manipulation or contain a whole bunch of variables just for making socket calls. That would be the violation of crossing abstraction layers and also of having one class/function do only one thing (SRP - Single Responsibility Principle).