On the other side, it can be interpreted following way: building software is building understanding - software is precise and executable knowledge. In this case, abstraction is "classical" cognitive trick to manage complexity and building knowledge. Ultimately nobody builds software for code, people build it to achieve something and software doesn't work in a vacuum it is also expecting some knowledge from the users. And in this case, repetition of pieces of code is not a big deal, but recognition of the same concepts (abstracts) in different places is important.
Just want to remind that ours (developers) pursuit for DRYness bites us often and it is not ultimate purpose to build DRYest code ever. The ultimate purpose is to make it work, make it right, make it fast. This is what Sandi Metz talks about:
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.
I'm thinking out loud.
On the other side, it can be interpreted following way: building software is building understanding - software is precise and executable knowledge. In this case, abstraction is "classical" cognitive trick to manage complexity and building knowledge. Ultimately nobody builds software for code, people build it to achieve something and software doesn't work in a vacuum it is also expecting some knowledge from the users. And in this case, repetition of pieces of code is not a big deal, but recognition of the same concepts (abstracts) in different places is important.
Just want to remind that ours (developers) pursuit for DRYness bites us often and it is not ultimate purpose to build DRYest code ever. The ultimate purpose is to make it work, make it right, make it fast. This is what Sandi Metz talks about:
The fact that you made the wrong "abstraction" doesn't invalidate my definition on Abstraction. ;)
For clarity: I didn't try to invalidate your definition. It was more thoughts out loud.
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?