> I can't seem to wrap my head around OOP. There's too many concepts in OOP. Which ones? You're familiar with structs, right? OO is just structs with a little

> I can't seem to wrap my head around OOP. There's too many concepts in OOP. Which ones? You're familiar with structs, right? OO is just structs with a little magic & sugar. Not even that much. Objects, methods, properties, instances, classes: Imagine if, when defining a struct type, you could put references to functions on it, such that any struct of that type would contain those same fields with references to the same functions you put in the type definition. Then, if you create a struct of that type, the compiler and/or runtime will helpfully and magically appends an extra argument to those function signatures, assigning it some conventional name ("this", perhaps) and, if you call such a function "on" a struct of that type, the compiler/runtime will quietly, in the background, pass a reference to the struct you called the function "on" in that last argument slot, so that within the function you can make use of the function's "parent" struct (as, perhaps, a variable named "this"). The struct type with slightly-magical function references is a class. The fields on the struct containing references to functions with the magical "this" argument appended when invoked, are methods. A struct of that struct-type is an object, or instance of the struct type, if you will. Fields on the struct are properties or members or whatever you like to call them. Static: What if you could tell the compiler/runtime not to bother appending that "this" argument to some of those functions you attached to a struct type definition? Or to have a given field on a struct type definition always point to the same location for every single struct of that type, so that they all essentially share a single variable? That's what "static" means. Inheritance: What if you could tell the compiler/runtime that it should associate one or more other struct type definitions with the struct type you're currently writing, and that if it can't find a given field (including ones that are refs to functions, aka methods) on a struct of this type, it should check an associated struct of the other type(s) and only error if it can't find it there, either. With the result that a struct type so constructed effectively contains all the fields of the structs associated with it, unless a duplicate exists on that child struct type, in which case that takes precedence. That's basically inheritance. It's all about setting up and manipulating those kinds of relationships & precedence for lookups. That's all. Abstract, et c.: Just ways to have the compiler enforce constraints and requirements on a struct type definition. Final I do solemnly swear this is a constant, not a variable. Now, there are implementation details under the hood for all this, but that covers actual usage, terminology, and concepts pretty well. You don't need to dig into the details of e.g. vtables (one tool for efficiently settling those inheritance-leveraging field lookups) unless you're implementing OO itself.