# abstraction

Abstraction is a computing technique that reduces complexity by representing relevant information while hiding technical complexity behind simpler APIs.

This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles.

## Beyond Inline Values: Evolving Strata's Storage Engine

DevFeed: [Beyond Inline Values: Evolving Strata's Storage Engine](<https://devfeed.tech/articles/beyond-inline-values-evolving-strata-s-storage-engine-39413.md>)

Original publisher: [Read original article](<https://n8z.dev/posts/beyond-inline-values/>)

Author: Nevin Zheng

Published: 2026-06-03T00:00:00Z

Content type: article

Language: en

Sources: [nevzheng](<https://devfeed.tech/sources/nevzheng.md>)

Topics: [Rust](<https://devfeed.tech/topics/rust.md>), [abstraction](<https://devfeed.tech/topics/abstraction.md>), [SQL](<https://devfeed.tech/topics/sql.md>), [olap](<https://devfeed.tech/topics/olap.md>)

Tags: [abstraction](<https://devfeed.tech/tags/abstraction.md>), [block](<https://devfeed.tech/tags/block.md>), [bootstrapping](<https://devfeed.tech/tags/bootstrapping.md>), [layout](<https://devfeed.tech/tags/layout.md>), [migration](<https://devfeed.tech/tags/migration.md>), [performance](<https://devfeed.tech/tags/performance.md>), [repo](<https://devfeed.tech/tags/repo.md>), [rust](<https://devfeed.tech/tags/rust.md>), [sql](<https://devfeed.tech/tags/sql.md>), [storage](<https://devfeed.tech/tags/storage.md>), [storage-engine](<https://devfeed.tech/tags/storage-engine.md>), [write-amplification](<https://devfeed.tech/tags/write-amplification.md>)

### AI overview

This architectural decision record proposes replacing Strata's inline value storage with a block-based abstraction. It describes the current Rust LSM storage engine and SQL layer, identifies flexibility and I/O amplification problems, compares options, and records the proposed direction.

### Source excerpt

An architectural decision record: why Strata is moving from inline values to block-based storage.

## Academic Chat with Murat and Aleksey: 5 Cs of the Invisible Curriculum.

DevFeed: [Academic Chat with Murat and Aleksey: 5 Cs of the Invisible Curriculum.](<https://devfeed.tech/articles/academic-chat-with-murat-and-aleksey-5-cs-of-the-invisible-curriculum-39542.md>)

Original publisher: [Read original article](<https://charap.co/academic-chat-with-murat-and-aleksey-5-cs-of-the-invisible-curriculum/>)

Author: Aleksey Charapko

Published: 2025-10-10T22:31:34Z

Content type: article

Language: en

Sources: [Aleksey Charapko](<https://devfeed.tech/sources/aleksey-charapko.md>)

Topics: [abstraction](<https://devfeed.tech/topics/abstraction.md>), [Continuation](<https://devfeed.tech/topics/continuation.md>)

Tags: [academic](<https://devfeed.tech/tags/academic.md>), [collective](<https://devfeed.tech/tags/collective.md>), [craft](<https://devfeed.tech/tags/craft.md>), [curiosity](<https://devfeed.tech/tags/curiosity.md>), [discussion](<https://devfeed.tech/tags/discussion.md>), [other-thoughts](<https://devfeed.tech/tags/other-thoughts.md>), [research](<https://devfeed.tech/tags/research.md>)

### AI overview

A discussion about the skills and qualities needed for PhD research, framed around the five Cs: Curiosity, Clarity, Craft, Community, and Courage. It especially considers research taste, levels of abstraction, curiosity, stopping points, and the influence of academic communities.

### Source excerpt

Instead of reading papers, last night, Murat and I engaged in an interesting discussion on skills, traits, and qualities needed for a PhD. This discussion came as a follow-up to Murat's recent blog on "The Invisible Curriculum of Research." In his blog, Murat discusses "Curiosity, Clarity, Craft, Community, and Courage" as skills/qualities of a good [...]

## Design is about the abstractions

DevFeed: [Design is about the abstractions](<https://devfeed.tech/articles/design-is-about-the-abstractions-39069.md>)

Original publisher: [Read original article](<https://blog.devdetails.com/p/design-is-about-the-abstractions>)

Author: Mike

Published: 2024-08-05T15:55:48Z

Content type: article

Language: en

Sources: [Dev Details](<https://devfeed.tech/sources/dev-details.md>)

Topics: [abstraction](<https://devfeed.tech/topics/abstraction.md>), [Architecture & Design](<https://devfeed.tech/topics/architecture-design.md>), [software-architecture](<https://devfeed.tech/topics/software-architecture.md>), [API](<https://devfeed.tech/topics/api.md>), [interfaces](<https://devfeed.tech/topics/interfaces.md>)

Tags: [abstraction](<https://devfeed.tech/tags/abstraction.md>), [api](<https://devfeed.tech/tags/api.md>), [architecture](<https://devfeed.tech/tags/architecture.md>), [interface](<https://devfeed.tech/tags/interface.md>), [software-architecture](<https://devfeed.tech/tags/software-architecture.md>), [software-design](<https://devfeed.tech/tags/software-design.md>), [software-engineering](<https://devfeed.tech/tags/software-engineering.md>)

### AI overview

The article explains how abstraction helps software and house design by hiding implementation details, defining interfaces and APIs, and indicating when a design contains enough detail to stop.

### Source excerpt

Abstractions simplify designs and tell us when to stop designing.

## Item 31: Respect abstraction contracts

DevFeed: [Item 31: Respect abstraction contracts](<https://devfeed.tech/articles/item-31-respect-abstraction-contracts-39289.md>)

Original publisher: [Read original article](<https://kt.academy/article/ek-respect-contracts>)

Published: 2024-07-22T00:00:00Z

Content type: tutorial

Language: en

Sources: [Kt. Academy](<https://devfeed.tech/sources/kt-academy.md>)

Topics: [abstraction](<https://devfeed.tech/topics/abstraction.md>)

Tags: [abstraction](<https://devfeed.tech/tags/abstraction.md>), [how-to](<https://devfeed.tech/tags/how-to.md>), [important](<https://devfeed.tech/tags/important.md>), [workshop-learning-programming](<https://devfeed.tech/tags/workshop-learning-programming.md>)

### AI overview

The article explains why respecting abstraction contracts matters and argues that technical possibility does not by itself justify an action.

### Source excerpt

Just because we can do something, does not mean we should. How to respect abstraction contracts and why it is so important.

## Item 30: Define contracts with documentation

DevFeed: [Item 30: Define contracts with documentation](<https://devfeed.tech/articles/item-30-define-contracts-with-documentation-39275.md>)

Original publisher: [Read original article](<https://kt.academy/article/ek-contracts-documentation>)

Published: 2024-07-08T00:00:00Z

Content type: tutorial

Language: en

Sources: [Kt. Academy](<https://devfeed.tech/sources/kt-academy.md>)

Topics: [Documentation](<https://devfeed.tech/topics/documentation.md>), [abstraction](<https://devfeed.tech/topics/abstraction.md>), [Code](<https://devfeed.tech/topics/code.md>), [implementation](<https://devfeed.tech/topics/implementation.md>), [Library](<https://devfeed.tech/topics/library.md>)

Tags: [abstraction](<https://devfeed.tech/tags/abstraction.md>), [code](<https://devfeed.tech/tags/code.md>), [documentation](<https://devfeed.tech/tags/documentation.md>), [implementation](<https://devfeed.tech/tags/implementation.md>), [library](<https://devfeed.tech/tags/library.md>), [workshop-learning-programming](<https://devfeed.tech/tags/workshop-learning-programming.md>)

### AI overview

This article explains how documentation defines contracts for library or module elements. It argues that clearly documenting expected behavior lets users depend on an abstraction rather than its current implementation, while allowing creators to change the implementation as long as the contract is preserved.

### Source excerpt

How do we express our library or module contracts and why are they so important.

## Item 26: Use abstraction to protect code against changes

DevFeed: [Item 26: Use abstraction to protect code against changes](<https://devfeed.tech/articles/item-26-use-abstraction-to-protect-code-against-changes-39269.md>)

Original publisher: [Read original article](<https://kt.academy/article/ek-abstraction-code-changes>)

Published: 2024-02-26T00:00:00Z

Content type: tutorial

Language: en

Sources: [Kt. Academy](<https://devfeed.tech/sources/kt-academy.md>)

Topics: [abstraction](<https://devfeed.tech/topics/abstraction.md>), [Code](<https://devfeed.tech/topics/code.md>), [Software Engineering](<https://devfeed.tech/topics/software-engineering.md>)

Tags: [abstraction](<https://devfeed.tech/tags/abstraction.md>), [classes](<https://devfeed.tech/tags/classes.md>), [code](<https://devfeed.tech/tags/code.md>), [database](<https://devfeed.tech/tags/database.md>), [display](<https://devfeed.tech/tags/display.md>), [password](<https://devfeed.tech/tags/password.md>), [software-engineering](<https://devfeed.tech/tags/software-engineering.md>), [sorting](<https://devfeed.tech/tags/sorting.md>), [threads](<https://devfeed.tech/tags/threads.md>), [validation](<https://devfeed.tech/tags/validation.md>), [workshop-learning-programming](<https://devfeed.tech/tags/workshop-learning-programming.md>)

### AI overview

This tutorial explains how abstraction protects code from changes. It covers extracting literal values into constants, separating algorithms into functions, and using abstractions to change implementation details without changing how code is used.

### Source excerpt

How do we abstract elements, and what are the consequences.

## Item 25: Each function should be written in terms of a single level of abstraction

DevFeed: [Item 25: Each function should be written in terms of a single level of abstraction](<https://devfeed.tech/articles/item-25-each-function-should-be-written-in-terms-of-a-single-level-of-abstraction-39291.md>)

Original publisher: [Read original article](<https://kt.academy/article/ek-single-layer-of-abstraction>)

Published: 2024-02-19T00:00:00Z

Content type: tutorial

Language: en

Sources: [Kt. Academy](<https://devfeed.tech/sources/kt-academy.md>)

Topics: [abstraction](<https://devfeed.tech/topics/abstraction.md>), [function](<https://devfeed.tech/topics/function.md>), [Programming](<https://devfeed.tech/topics/programming.md>), [Computer science](<https://devfeed.tech/topics/computer-science.md>)

Tags: [abstraction](<https://devfeed.tech/tags/abstraction.md>), [code](<https://devfeed.tech/tags/code.md>), [computer-science](<https://devfeed.tech/tags/computer-science.md>), [function](<https://devfeed.tech/tags/function.md>), [how-to](<https://devfeed.tech/tags/how-to.md>), [programming](<https://devfeed.tech/tags/programming.md>), [workshop-learning-programming](<https://devfeed.tech/tags/workshop-learning-programming.md>)

### AI overview

The article explains why each function should be written at a single level of abstraction. It introduces abstraction layers from hardware and machine instructions through Assembly, compilers, and higher-level languages, arguing that well-separated layers reduce the need to understand lower-level implementation details.

### Source excerpt

Why each function should be written in terms of a single level of abstraction and how to achieve it.

## Abstraction design: Introduction

DevFeed: [Abstraction design: Introduction](<https://devfeed.tech/articles/abstraction-design-introduction-39268.md>)

Original publisher: [Read original article](<https://kt.academy/article/ek-abstraction>)

Published: 2024-02-05T00:00:00Z

Content type: tutorial

Language: en

Sources: [Kt. Academy](<https://devfeed.tech/sources/kt-academy.md>)

Topics: [abstraction](<https://devfeed.tech/topics/abstraction.md>), [Programming](<https://devfeed.tech/topics/programming.md>), [Object-oriented programming (OOP)](<https://devfeed.tech/topics/oop.md>), [interfaces](<https://devfeed.tech/topics/interfaces.md>), [Functional programming](<https://devfeed.tech/topics/functional-programming.md>)

Tags: [abstraction](<https://devfeed.tech/tags/abstraction.md>), [concepts](<https://devfeed.tech/tags/concepts.md>), [core](<https://devfeed.tech/tags/core.md>), [function](<https://devfeed.tech/tags/function.md>), [interfaces](<https://devfeed.tech/tags/interfaces.md>), [object-oriented](<https://devfeed.tech/tags/object-oriented.md>), [programming](<https://devfeed.tech/tags/programming.md>), [workshop-learning-programming](<https://devfeed.tech/tags/workshop-learning-programming.md>)

### AI overview

This introduction explains abstraction as a form of simplification that hides complexity by deciding what to expose and what to conceal. It discusses abstractions in object-oriented and functional programming, including interfaces, classes, functions, and higher-level operations, with examples involving Java and Kotlin.

### Source excerpt

What is abstraction in programming and why is it so important.

## Why the DRY Principle Is Often Misunderstood in Software Design

DevFeed: [Why the DRY Principle Is Often Misunderstood in Software Design](<https://devfeed.tech/articles/dry-do-repeat-yourself-39901.md>)

Original publisher: [Read original article](<https://mende.io/blog/dry-do-repeat-yourself/>)

Author: tobi@techunicorn.builders (Tobias Mende)

Published: 2022-04-30T13:13:00Z

Content type: opinion

Language: en

Sources: [Tobias Mende](<https://devfeed.tech/sources/tobias-mende.md>)

Topics: [Software Engineering](<https://devfeed.tech/topics/software-engineering.md>), [Architecture & Design](<https://devfeed.tech/topics/architecture-design.md>), [abstraction](<https://devfeed.tech/topics/abstraction.md>), [reuse](<https://devfeed.tech/topics/reuse.md>), [maintenance](<https://devfeed.tech/topics/maintenance.md>)

Tags: [abstraction](<https://devfeed.tech/tags/abstraction.md>), [component](<https://devfeed.tech/tags/component.md>), [dependencies](<https://devfeed.tech/tags/dependencies.md>), [maintenance](<https://devfeed.tech/tags/maintenance.md>), [practices-software-development-software-craft](<https://devfeed.tech/tags/practices-software-development-software-craft.md>), [reuse](<https://devfeed.tech/tags/reuse.md>), [software-design](<https://devfeed.tech/tags/software-design.md>)

### AI overview

The article argues that the DRY principle is frequently misapplied in software development. Reusing code can reduce duplication but may introduce dependencies, rigid contracts, and abstractions that are difficult to change, especially when systems evolve independently.

### Source excerpt

DRY - DO repeat yourself When I started my career as a software developer and already during university, almost no principle was mentioned as often as the DRY principle: "Do not repeat yourself"

## Thoughts after a Year of Math ∩ Programming

DevFeed: [Thoughts after a Year of Math ∩ Programming](<https://devfeed.tech/articles/thoughts-after-a-year-of-math-programming-40276.md>)

Original publisher: [Read original article](<https://www.jeremykun.com/2012/06/12/thoughts-after-a-year-of-math-programming/>)

Published: 2012-06-12T06:00:22Z

Content type: opinion

Language: en

Sources: [Jeremy Kun](<https://devfeed.tech/sources/jeremy-kun.md>)

Topics: [Programming](<https://devfeed.tech/topics/programming.md>), [math](<https://devfeed.tech/topics/math.md>), [Software Engineering](<https://devfeed.tech/topics/software-engineering.md>), [Algorithms](<https://devfeed.tech/topics/algorithms.md>), [abstraction](<https://devfeed.tech/topics/abstraction.md>)

Tags: [abstraction](<https://devfeed.tech/tags/abstraction.md>), [algorithms](<https://devfeed.tech/tags/algorithms.md>), [math](<https://devfeed.tech/tags/math.md>), [mathematics](<https://devfeed.tech/tags/mathematics.md>), [programming](<https://devfeed.tech/tags/programming.md>), [software-design](<https://devfeed.tech/tags/software-design.md>)

### AI overview

A reflective commentary on the relationship between programming and mathematics. It argues that programming is useful for exploring questions and automating tasks, while mathematics helps distill problems, inform algorithms, and support abstraction and software design.

### Source excerpt

After a year of writing this blog, what have I learned about the nature of the relationship between computer programs and mathematics? Here are a few notes that sum up my thoughts, roughly in order of how strongly I agree with them. I'd love to hear your thoughts in the comments. Programming is absolutely great for exploring questions and automating tasks. Mathematics is absolutely great for distilling the soul of a problem.

## Generalized Functions -- A Primer

DevFeed: [Generalized Functions -- A Primer](<https://devfeed.tech/articles/generalized-functions-a-primer-40275.md>)

Original publisher: [Read original article](<https://www.jeremykun.com/2012/06/06/generalized-functions/>)

Published: 2012-06-06T20:57:05Z

Content type: tutorial

Language: en

Sources: [Jeremy Kun](<https://devfeed.tech/sources/jeremy-kun.md>)

Topics: [Mathematics](<https://devfeed.tech/topics/mathematics.md>), [Math and Logic](<https://devfeed.tech/topics/math-and-logic.md>), [abstraction](<https://devfeed.tech/topics/abstraction.md>), [Programming](<https://devfeed.tech/topics/programming.md>)

Tags: [abstraction](<https://devfeed.tech/tags/abstraction.md>), [fourier-analysis](<https://devfeed.tech/tags/fourier-analysis.md>), [fourier-transform](<https://devfeed.tech/tags/fourier-transform.md>), [functional-analysis](<https://devfeed.tech/tags/functional-analysis.md>), [generalized-functions](<https://devfeed.tech/tags/generalized-functions.md>), [linear-algebra](<https://devfeed.tech/tags/linear-algebra.md>), [mathematics](<https://devfeed.tech/tags/mathematics.md>), [primer](<https://devfeed.tech/tags/primer.md>), [programming](<https://devfeed.tech/tags/programming.md>), [theory](<https://devfeed.tech/tags/theory.md>)

### AI overview

This primer develops a more rigorous mathematical framework for Fourier transforms. It motivates the search for a class of functions that remains well behaved under the Fourier transform and its inverse, while avoiding divergent integrals.

### Source excerpt

Last time we investigated the naive (which I'll henceforth call "classical") notion of the Fourier transform and its inverse. While the development wasn't quite rigorous, we nevertheless discovered elegant formulas and interesting properties that proved useful in at least solving differential equations. Of course, we wouldn't be following this trail of mathematics if it didn't result in some worthwhile applications to programming. While we'll get there eventually, this primer will take us deeper down the rabbit hole of abstraction.

## Languages in Computer Science

DevFeed: [Languages in Computer Science](<https://devfeed.tech/articles/languages-in-computer-science-40706.md>)

Original publisher: [Read original article](<https://radek.io/posts/language-in-computer-science/>)

Published: 2011-10-21T00:00:00Z

Content type: tutorial

Language: en

Sources: [Radek Pazdera](<https://devfeed.tech/sources/radek-pazdera.md>)

Topics: [Computer science](<https://devfeed.tech/topics/computer-science.md>), [Mathematics](<https://devfeed.tech/topics/mathematics.md>), [abstraction](<https://devfeed.tech/topics/abstraction.md>), [iteration](<https://devfeed.tech/topics/iteration.md>)

Tags: [abstraction](<https://devfeed.tech/tags/abstraction.md>), [computer](<https://devfeed.tech/tags/computer.md>), [computer-science](<https://devfeed.tech/tags/computer-science.md>), [concatenation](<https://devfeed.tech/tags/concatenation.md>), [iteration](<https://devfeed.tech/tags/iteration.md>), [language](<https://devfeed.tech/tags/language.md>)

### AI overview

This tutorial introduces formal languages as sets of strings over an alphabet. It explains how set operations and string operations extend to languages, then defines language concatenation, powers, and positive and zero-inclusive iteration.

### Source excerpt

Certainly not the typical ones.

## Errors as Part of Interface

DevFeed: [Errors as Part of Interface](<https://devfeed.tech/articles/errors-as-part-of-interface-40684.md>)

Original publisher: [Read original article](<https://radek.io/posts/errors-as-part-of-interface/>)

Published: 2011-09-21T00:00:00Z

Content type: tutorial

Language: en

Sources: [Radek Pazdera](<https://devfeed.tech/sources/radek-pazdera.md>)

Topics: [Error Handling](<https://devfeed.tech/topics/error-handling.md>), [abstraction](<https://devfeed.tech/topics/abstraction.md>), [Exception](<https://devfeed.tech/topics/exception.md>), [client](<https://devfeed.tech/topics/client.md>), [file](<https://devfeed.tech/topics/file.md>)

Tags: [abstraction](<https://devfeed.tech/tags/abstraction.md>), [client](<https://devfeed.tech/tags/client.md>), [error-handling](<https://devfeed.tech/tags/error-handling.md>), [errors](<https://devfeed.tech/tags/errors.md>), [exception](<https://devfeed.tech/tags/exception.md>), [file](<https://devfeed.tech/tags/file.md>)

### AI overview

The article explains that errors should be reported at the same level of abstraction as the unit, class, or routine where they occur. It argues that error reports should describe the actionable problem for the receiver rather than expose low-level causes such as memory-allocation failures.

### Source excerpt

Steve McConnells idea about proper error handling.

## Design Patterns: Bridge

DevFeed: [Design Patterns: Bridge](<https://devfeed.tech/articles/design-patterns-bridge-40672.md>)

Original publisher: [Read original article](<https://radek.io/posts/design-patterns-bridge/>)

Published: 2011-08-26T00:00:00Z

Content type: tutorial

Language: en

Sources: [Radek Pazdera](<https://devfeed.tech/sources/radek-pazdera.md>)

Topics: [Software Engineering](<https://devfeed.tech/topics/software-engineering.md>), [Architecture & Design](<https://devfeed.tech/topics/architecture-design.md>), [abstraction](<https://devfeed.tech/topics/abstraction.md>), [implementation](<https://devfeed.tech/topics/implementation.md>), [interface](<https://devfeed.tech/topics/interface.md>), [Inheritance](<https://devfeed.tech/topics/inheritance.md>), [C++](<https://devfeed.tech/topics/c-plus-plus.md>), [Python](<https://devfeed.tech/topics/python.md>)

Tags: [abstraction](<https://devfeed.tech/tags/abstraction.md>), [bridge](<https://devfeed.tech/tags/bridge.md>), [c-plus-plus](<https://devfeed.tech/tags/c-plus-plus.md>), [code](<https://devfeed.tech/tags/code.md>), [design-patterns](<https://devfeed.tech/tags/design-patterns.md>), [examples](<https://devfeed.tech/tags/examples.md>), [github](<https://devfeed.tech/tags/github.md>), [implementation](<https://devfeed.tech/tags/implementation.md>), [inheritance](<https://devfeed.tech/tags/inheritance.md>), [interfaces](<https://devfeed.tech/tags/interfaces.md>), [python](<https://devfeed.tech/tags/python.md>), [software-design](<https://devfeed.tech/tags/software-design.md>)

### AI overview

An introduction to the Bridge design pattern, explaining how it decouples abstraction from implementation so they can vary independently. The article presents diagrams and C++ and Python examples, and contrasts Bridge with Adapter.

### Source excerpt

Software design patterns by example

## Interface Segregation Principle

DevFeed: [Interface Segregation Principle](<https://devfeed.tech/articles/interface-segregation-principle-40702.md>)

Original publisher: [Read original article](<https://radek.io/posts/interface-segregation-principle-in-software-design/>)

Published: 2011-08-12T00:00:00Z

Content type: tutorial

Language: en

Sources: [Radek Pazdera](<https://devfeed.tech/sources/radek-pazdera.md>)

Topics: [Software Engineering](<https://devfeed.tech/topics/software-engineering.md>), [interfaces](<https://devfeed.tech/topics/interfaces.md>), [Architecture & Design](<https://devfeed.tech/topics/architecture-design.md>), [Inheritance](<https://devfeed.tech/topics/inheritance.md>), [abstraction](<https://devfeed.tech/topics/abstraction.md>), [reuse](<https://devfeed.tech/topics/reuse.md>)

Tags: [abstraction](<https://devfeed.tech/tags/abstraction.md>), [code](<https://devfeed.tech/tags/code.md>), [inheritance](<https://devfeed.tech/tags/inheritance.md>), [interfaces](<https://devfeed.tech/tags/interfaces.md>), [reuse](<https://devfeed.tech/tags/reuse.md>), [software-design](<https://devfeed.tech/tags/software-design.md>), [solid](<https://devfeed.tech/tags/solid.md>)

### AI overview

This tutorial explains the Interface Segregation Principle, the final principle in the SOLID object-oriented design set. It describes how oversized interfaces create unused or dummy methods and recommends splitting them into smaller, purpose-specific interfaces, illustrated with a car example involving automatic transmission and air conditioning.

### Source excerpt

I build software products and write on the Internet.

## Dependency Inversion Principle

DevFeed: [Dependency Inversion Principle](<https://devfeed.tech/articles/dependency-inversion-principle-40667.md>)

Original publisher: [Read original article](<https://radek.io/posts/dependency-inversion-principle/>)

Published: 2011-08-10T00:00:00Z

Content type: article

Language: en

Sources: [Radek Pazdera](<https://devfeed.tech/sources/radek-pazdera.md>)

Topics: [Dependency Inversion](<https://devfeed.tech/topics/dependency-inversion.md>), [abstraction](<https://devfeed.tech/topics/abstraction.md>), [interface](<https://devfeed.tech/topics/interface.md>), [object](<https://devfeed.tech/topics/object.md>), [modules](<https://devfeed.tech/topics/modules.md>), [Software](<https://devfeed.tech/topics/software.md>)

Tags: [abstraction](<https://devfeed.tech/tags/abstraction.md>), [dependency-inversion](<https://devfeed.tech/tags/dependency-inversion.md>), [dependency-inversion-principle](<https://devfeed.tech/tags/dependency-inversion-principle.md>), [interface](<https://devfeed.tech/tags/interface.md>), [interfaces](<https://devfeed.tech/tags/interfaces.md>), [object-oriented](<https://devfeed.tech/tags/object-oriented.md>), [software](<https://devfeed.tech/tags/software.md>), [solid](<https://devfeed.tech/tags/solid.md>)

### AI overview

The article explains the Dependency Inversion Principle, the D in SOLID, for object-oriented software design. It argues that high-level and low-level modules should depend on abstractions, while details should depend on those abstractions, improving module reuse and reducing direct coupling.

### Source excerpt

SOLID Object-Oriented Design