we want to avoid copy-pasting, or DRY, that's why we want to "abstract" those repetitive pieces into only 1 piece
In my world that's called "refactoring". You can stay in the same abstraction layer while refactoring, e.g. you build a simulation like The Sims and have objects like Cars as well as Trucks with their own constructor. When refactoring you find duplicate code in these constructors and decide to apply the DRY principle. This might result in a VehicleFactory, which is a generalisation, but not an abstraction. You're still in the object/terminology world of your Sims and you might also find a NatureFactory that will create Trees and Flowers in your Sims' world. All these things are in the same abstraction layer. Going the ladder one layer up, you might find your VehicleFactory and NatureFactory being called in initialiseGame. You know that you're in a different abstraction layer when you've got a different vocabulary. The Sims know what a Tree is and what a Car is, because these are the objects in their world. But a Sim wouldn't understand initialiseGame, because that's the vocabulary of the player.
Hmm. We might be speaking of an “abstraction” as a either concept or as a component of a software system. In each case, reuse is a useful property of an abstraction and a good reason to keep it. However, I might create an abstraction to be used only once and still be justified in that, as it might allow me to better organize my thoughts. I could also likely reuse things that are not abstractions, such as a doorknob. (Though one could argue that my using the word doorknob to describe a meaningful group of atoms is nothing if not an abstraction... ?)
Therefore, in my view, reuse is a benefit of abstraction but not it’s definition.
Speaking of terminology...
In my world that's called "refactoring". You can stay in the same abstraction layer while refactoring, e.g. you build a simulation like The Sims and have objects like Cars as well as Trucks with their own constructor. When refactoring you find duplicate code in these constructors and decide to apply the DRY principle. This might result in a VehicleFactory, which is a generalisation, but not an abstraction. You're still in the object/terminology world of your Sims and you might also find a NatureFactory that will create Trees and Flowers in your Sims' world. All these things are in the same abstraction layer. Going the ladder one layer up, you might find your VehicleFactory and NatureFactory being called in initialiseGame. You know that you're in a different abstraction layer when you've got a different vocabulary. The Sims know what a Tree is and what a Car is, because these are the objects in their world. But a Sim wouldn't understand initialiseGame, because that's the vocabulary of the player.
Hmm. We might be speaking of an “abstraction” as a either concept or as a component of a software system. In each case, reuse is a useful property of an abstraction and a good reason to keep it. However, I might create an abstraction to be used only once and still be justified in that, as it might allow me to better organize my thoughts. I could also likely reuse things that are not abstractions, such as a doorknob. (Though one could argue that my using the word doorknob to describe a meaningful group of atoms is nothing if not an abstraction... ?)
Therefore, in my view, reuse is a benefit of abstraction but not it’s definition.
So you consider generalization and abstraction as different things? How would you define both?