Abstraction patterns: making code reliably better without deep understanding

By Kate Gregory

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.





Your Privacy

By clicking "Accept Non-Essential Cookies" you agree ACCU can store non-essential cookies on your device and disclose information in accordance with our Privacy Policy and Cookie Policy.

Current Setting: Non-Essential Cookies REJECTED


By clicking "Include Third Party Content" you agree ACCU can forward your IP address to third-party sites (such as YouTube) to enhance the information presented on this site, and that third-party sites may store cookies on your device.

Current Setting: Third Party Content EXCLUDED



Settings can be changed at any time from the Cookie Policy page.