Abstraction patterns:

making code reliably better without deep understanding

When we design before coding, we create abstractions: classes, member variables, functions, etc. The designer must understand the domain the program models: business, finance, science, or the rules of a game. Often, we must ask users deep questions about what they do, so the software is more likely to meet their needs. Something similar happens when we design major new functionality for existing applications.
There’s another entire kind of abstraction design that we do not teach explicitly. It happens when refactoring working code. These 5 variables seem to go together; let’s put them in a class. These hundred lines of code seem to be doing a single thing; let’s make them a function. This abstraction work doesn’t draw on a deep knowledge of the business or science – it uses cues within the code itself.
This talk will show you those cues and patterns, and how to make code readable and maintainable when you don’t necessarily know how it works and don’t have a deep understanding of the domain it models. You can recognize these patterns in your own code as you write it, or 20 year old code you’ve never seen before: either way your code will be better with a little more abstraction.

Kate Gregory

I have been paid to program for over 40 years now, and it’s almost all been in C++. I code, teach, write, and help people, from an office in rural Ontario. You can take my courses on Pluralsight or watch my talks at conferences the world over. I’m also active in #include<C++>, trying to make the C++ community more welcoming and inclusive.