
When did the OOP principles change? - luminousmen
I have a stupid question - when did the Object-oriented programming principles change? In my childhood, I was told that there are three OOP principles: encapsulation, inheritance, and polymorphism. Now I get more and more articles about four OOP principles - one new came out eventually, it&#x27;s called abstraction. One of the common definitions of abstraction: “An abstraction denotes the essential characteristics of an object that distinguish it from all other kinds of object and thus provide crisply defined conceptual boundaries, relative to the perspective of the viewer.” — G. Booch, Object-Oriented Design With Applications, Benjamin&#x2F;Cummings, MenloPark, California, 1991. Is it really a principle, it seems like it the idea on which other principles was built.
======
PaulHoule
Today many pedants rehash old lists of what the definition of OOP is and I
think it's not useful. You see articles in broken English spammed to the Java
discussion board on LinkedIn and the occasional person wanders into Hacker
News traumatized by a job interview where they were asked to come up with a
specific list, etc.

Abstraction is a basic principle for dealing with life, never mind software.
For instance, imagine you are keeping track of bowling scores.

Well, you probably use the abstraction of "integer". Integer is overkill
however because it can be negative, and could possible take an infinite amount
of space to represent. Practically you might write the scores by hand with
base-10 arabic numerals and you know how to execute an algorithm for abstract
operations such as "addition".

Doing it on a computer?

Bowling scores can be as high as 300 so a "int8" is not quite big enough, but
a "int16" is just fine and you wouldn't care if it was signed or unsigned.

In the 1960s you would learn how addition is implemented in circuitry if you
studied computer science, today you might not -- you don't need to because
Intel or ARM did it for you.

If there is a real problem with "Paradigm X" where "X" could be "OOP" or
anything else, is that software tends to reify one particular view of a
situation whereas different people involved in the situation see it
differently.

~~~
seeker61
Extremely confusing discourse. I can only assume that was your goal.

~~~
PaulHoule
I wish I could explain it better.

It is not some glib mantra like REST or SOLID or SCRUM that you can repeat
over and over again and imagine that you understand something.

It's about the gap between the map and the territory which is the most
mysterious and confusing place in the universe. (e.g. the "Dark Matter" is
there)

------
taylodl
Our understanding and experience with OOP has evolved significantly since
1991. Heck, the GoF book didn't come out until 1994! You are correct that
encapsulation, inheritance and polymorphism used to be preached. Then
Microsoft brought out COM and noted _you really don 't need_ inheritance.

Fast-forward to 2019 and OOP is on SOLID ground:

S - Single responsibility principle

O - Open-closed principle

L - Liskov substitution principle

I - Interface segregation principle

D - Dependency inversion principle

I would argue that abstraction is the base principle of all programming and
really isn't terribly useful principle with which to differentiate OOP.

------
through
Perhaps your or another’s understanding changed. Avoid the cargo cult of
millennial software design. It’s generally polluted.

It does no harm to reference the GoF that perhaps the same G. Booch is
associated with:

Design Patterns: Elements of Reusable Object-Oriented Software

Replace word first thinking with thought first thinking and you’ll be fine.

