More or less; the implementation doesn’t have to already exist when the abstraction is defined. You can make more implementations later. Consider the case of files – we used to read them mostly from tape, and then later floppy disks, HDDs, SSDs… now we’ve got NVME, and who knows what else in the future.

Usually an abstraction hides the details of how exactly some operation is performed so you can work at a higher level.

In the case of a file on a hard disk, you don’t need to think about how to move motors or interpret the pattern of oscillations of magnetic orientation on a metal plate to work with it. You work at a more abstract level that gives you methods like open and read and seek over a linear block of bytes. When you swap out the HDD for an SSD code that works with “files” still works even though at the low level there are no more motors and you’re dealing with electrical signals and flash memory chip controllers under the hood.

That same code will likely still work if we come up with some crazy 3D memory crystal technology that lets you fit petabytes in your pocket, or some bizarre biological computer that lets you encode data in DNA; as long as you can access it with open and read you don’t have to care what’s going on under the hood… mostly.

It is worth noting that a lot of abstractions are leaky. We try to paper over the differences so you don’t have to think about the full complexity of what’s going on, but sometimes you can’t quite get away from those details…

When you start looking at files in terms of operations like open, read, write, close… then you realize you can make things like network requests using the same interface. Network requests tend to fail unpredictably much more often than reads and writes from a local HDD or SSD though, so Network File Systems often have strange and annoying behaviors where that underlying reality causes problems with assumptions that seemed reasonable to the authors of software who thought they were working with local files… (If you’ve ever had your entire desktop freeze up because your organization set up /home as a network mount which became temporarily inaccessible, or run into sudo refusing to operating on a file because the remote end does not have permission to access it… you’ve seen that leakiness in practice!)

Also, Unix famously popularized the “everything is a file” idea – which works for way more things than you might expect. I can open a “file” on my computer and read a sequence of joystick positions back out of it as they’re generated in real time… but I can’t seek backwards or forwards. I can open files under /sys or /proc and write changes into “files” that immediately affect things like the maximum power that my GPU can use and affect running programs in complex ways! The OS exposes those operations through a file-like interface to make it easy for any tool that works with files to interact with.