When did the OOP principles change?
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'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/Cummings, MenloPark, California, 1991. Is it really a principle, it seems like it the idea on which other principles was built.
5 comments
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.
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.
Extremely confusing discourse. I can only assume that was your goal.
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)
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)
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.
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.
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.
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.