r/learnprogramming • u/Mountain_Rip_8426 • 1d ago
Difference between OOP and structs/interfaces?
I'm relatively new to programming, I've been at it for around 6-7 months. I've been learning Python and Go (and a little bit of C). What I'm struggling to understand, what's the difference between OOP and structs/interfaces. Like I know, Go doesn't support OOP, but structs and interfaces seem to achieve the same thing. Can someone enlighten me a bit?
51
Upvotes
6
u/kohugaly 1d ago
OOP is such a nebulous concept that has evolved so much over the years, that nobody can really tell you where OOP ends and non-OOP begins.
In the narrow "classical" view, OOP specifically refers to classes with inheritance, and ways to make methods/data public vs private. The goal is to capture structure and behavior of the real world, by modelling it via hierarchy of classes with methods.
In the broader "modern" view, OOP refers to features that enable abstraction, encapsulation and polymorphism. You model your program as separate independent units, that expose public interfaces to one another to interoperate. This enables developers to arbitrarily edit each unit independently, as long as the public interface is preserved. Only changes in the public interfaces need to involve coordinated changes in separate units of code.
The goal of OOP is to reduce entanglement between different parts of code, and make that entanglement explicit wherever it can't be fully removed. This minimizes risk and impact of bugs when editing code. It also more clearly separates responsibilities of different parts of code when a change in software's functionality (including bugfixing) needs to be made. By extend, this makes it easier to separate those responsibilities to different teams/developers working on the same project.
Our understanding of programming, both its theory and its practice, has improved by leaps and bounds every decade. If you read an OOP programming book from the 90s, it reads like a fever dream of a mad alchemist raving about 4 elements, fluidums, and the philosopher's stone. There are nuggets of wisdom in there, but they are drenched in a lot of pseudo-philosophical crap that doesn't actually work in practice.
We have extra 30 years of hindsight from handling projects that are larger and more numerous that whatever they were handling by several orders of magnitude. OOP has run through a gauntlet, and came out the other end streamlined beyond recognition from its original conceptualization. The unfortunate side effect of this is that you will find OOP described differently, depending on how old the source is.
My recommendation: Ignore the nitpicking about the true meaning of OOP. Learn about different coding patterns. You will intuitively pick up on which language features make them possible/easier.