having only one sprite that represents all the "tiles" you see on the screen won't increase the performance of your program one bit. you still have to write the same amount of if()'s . ok, it decreases memory usage a bit, but that doesn't matter anyways since sprites themselfs are not big at all. calling methods from different objects doesn't make a single performance difference, look up wikipedia or something how c++ is translated into machine code.
also only having one sprite completely messes up the most design patterns. you should keep the idea of object oriented design (you know, you try to program stuff like you think about it in real life). when you see 20 balls on the ground, do you see 20 different balls or just the same ball that is rendered 20 times?
zoning is better. split up your map into different zones. every zone knows which objects are currently in it. in addition, every zone knows which zone is next to it. it makes sure that objects are correctly translatet between zones.
you just have to make sure that only the zone which the player can currently see is calculated.
of course thats just the standard idea. if you try to program a more complex game or something you'll end up having to adapt this whole idea a lot.
This is all correct, but that doesn't change the fact that there are certainly cases when you don't want a million sprites of the same image.
There's always a trade-off between CPU and memory. Usually several sprites is not a problem, but there is certainly an extreme case where the size of a sprite will become significant.
And as for "correct OOP," good game programmers know when OOP paradigms are good for code maintainability and when it's time to throw them out the window because the performance trade-off is too much. If games were all about making the most beautiful code possible, we wouldn't even be using C++. Sometimes you optimize the hell out of a critical loop to the point where the code is nearly incomprehensible without an essay in comments, but sometimes that's what you need to do. Sometimes you declare and calculate on variables in weird orders to optimize for a console's pipelining. Sometimes it's really, really ugly code. But it's fast, and ultimately that's what matters. Also, you can always (and should) comment stuff like this.