Thank you! It's Ashby Law's consequence. You need a metasystem transition to move forward. You need tools such as autonomy blackboxes to manage growing complexity. Now we use this experience of complexity management from software development in many other fields of management.
Yourdin and Constantine "Structured Design" -- I still keep that book handy. When I first came across OO with it's Platonic Forms inheritance idea, I immediately thought, inheritance codifies pathological connections. Break to parent and all the children break. Not a good idea.
„everybody already knows this“… if only. a lot of java code these days puts a lot of stuff into singletons called ‚services‘, turning it into a procedural language. some people also declare oop or horizontal layers (which are levels of abstraction) dead. react apps are the worst here, mixing css, html and code together so that ux had to turn to tools like figma. at least with ‚signals‘ mvc is currently having a comeback in web programming. with a bit of luck also ‚application models‘ (view -> application model -> domain model) and the ‚humble object‘ pattern (almost no code in the view layer so that the ui behaviour is completely in the application layer) in the 1980 smalltalk edition of byte magazine, they described their vision that oop/adt will enable users to build/modify their own software, using frameworks providing the necessary levels of abstraction. the software crisis might be over, but we have now something worse: an educational crisis. and for that reason i still consider barbara liskov‘s adt paper required reading for every software engineer.
Just a correction and modification of some concepts in OOP !!! ------- Abstraction is not that concept of showing or providing only the important things or hiding all unnecessary or complex details from the user (the programmer), as everyone thinks !!! All peoples explained that Abstraction is to provide only what the user can get, in short, to provide only the Important points in the classes that will be instanciated using an Object, and this is unfortunately wrong.... And if it was actually in this sense, the name would have been Only-Important-members or Hidding Data and so on... Also there is no Pillar named Abstract Data or Data Abstraction !!! --------- In short, this concept is part of the definition of Encapsulation and not Abstraction, and it is very close to the concept of inheritance rules more than Encapsulation --------- Linguistically: Abstraction means intangible or imaginary or virtual or the opposite of Concrete which means tangible, real or active --------- Programmatically: It specifically means the Class and the Interface (interface is not available in all programming languages). The important thing is the Class in itself. And any Class in OOP is considered as a Template, Model, or Map of something in Reality. That thing may be real or imaginary, and as it may be tangible or intangible, it does not matter the Projection and how .... but it matters The Classes that will Ultimately Express an Entity, Component, or Object that we will deal with later.... -------- So Abstraction in OOP will be like that: Modeling the Real World. and No more than Modelling Definition .. -------- There are also inactive, intangible, virtual, or Abstract Classes that we call them Class Models or Base Classes, and they are somewhat similar to the Interface. This type has a directive of type Abstract and it does not accept instanciate with Objects, that is, it has no Objects to represent it (No Instances). And her task is Only to make a Model or Template for her children's that inherited from and finally can share members from that base Abstract Classe.(Model of SubClasses) And this technique is also within the definition of the corner Abstraction And my concept here is focus in modeling and not in the role of the abstract class (because its role in terms of providing only what the sons classes can share as members , this is a part from the corner of rule inheritance) finally : Abstract classes is an Abstract Model for a Concrete classes Where this concrete will be a Models for some objects in our Real World... -------- Interfaces are also a Model where Classes use them in-order to benefit from those members in that Interface.. So, Abstraction OOP is only about these three things .. ------ As for the definition that Peoples explained in the ethernet, it is related to Encapsulation and Inheritance rules and not Abstraction at All .. ----- Abstraction is the first Step Rule of OOP Pillars wich is the Classes and Interfaces ... Abstraction is not more than a Modelling ... maybe virtual methods are also a part of this Cake also .. ---- but in general: A home Construction Engineer cannot start Constructing any home without a Blueprint !! that's why Abstraction is tied for.. (it's the first Step into OOP) same thing with Objects (no Classes[MODELLING] no Objects[REAL THINGS] !!) ----- And thank you for your understanding ...
From the original paper by Barbara Liskov: [The Meaning of Abstraction] : "What we desire from an abstraction is a mechanism which permits the expression of relevant details and the suppression of irrelevant details. In the case of programming, the use which my be made of an abstraction is relevant; the way in which the abstraction is implemented is irrelevant."
Professor Barbara Liskov, i´m reading your original paper: PROGRAMMING WITH ABSTRACT DATA TYPES. Best Regards from Canguaretama-RN, Brazil.
Thank you for your work Mrs. Barbara, much respect for one of the people that brought upon the way we write software today
call her Dr.Liskov
I hope this audience understands the legend that is right in front of them.
Thank you Barabara❤
I came here to learn about abstraction, I found the inventor of computer abstraction.
RUclips so cool.
I was looking for the same thing! Did you find anything tasty?
My Hero! What an excellent talk. Why can't all talks about software be like this
what a legend she is
She is just amazing got to know her from the soLid principles. Legend.
living legend
Thank you Ms. Barbara .. this is clearly explained in detailed.
Came across this video and this is really interesting !
thanks. it is extremely interesting to trace origin of concepts and ideas.
Amazing , thank you for advancing technology !
Great talk! Thanks for sharing.
I really enjoyed listening to your talk!
Great contribution by barbara.
A gem of a video.
Thank you! It's Ashby Law's consequence. You need a metasystem transition to move forward. You need tools such as autonomy blackboxes to manage growing complexity. Now we use this experience of complexity management from software development in many other fields of management.
Programming towards Category Theory.
Brilliant!
Can I download the video then add spanish subtitles and load again at my own channel? please?
Legend.
True Gem
But C++ was in development from 1978 to 1987, which did most of the heavy lifting of OOPs. Java should get credit for platform independence.
2:36 she also self thought programmer nothing changed much till now....
How Data Abstraction changed Dave Cullen
incredible
Yourdin and Constantine "Structured Design" -- I still keep that book handy. When I first came across OO with it's Platonic Forms inheritance idea, I immediately thought, inheritance codifies pathological connections. Break to parent and all the children break. Not a good idea.
oo is not about inheritance. focusing too much on classes leads to an anti pattern dubbed „class oriented programming“.
„everybody already knows this“… if only. a lot of java code these days puts a lot of stuff into singletons called ‚services‘, turning it into a procedural language.
some people also declare oop or horizontal layers (which are levels of abstraction) dead.
react apps are the worst here, mixing css, html and code together so that ux had to turn to tools like figma. at least with ‚signals‘ mvc is currently having a comeback in web programming. with a bit of luck also ‚application models‘ (view -> application model -> domain model) and the ‚humble object‘ pattern (almost no code in the view layer so that the ui behaviour is completely in the application layer)
in the 1980 smalltalk edition of byte magazine, they described their vision that oop/adt will enable users to build/modify their own software, using frameworks providing the necessary levels of abstraction.
the software crisis might be over, but we have now something worse: an educational crisis.
and for that reason i still consider barbara liskov‘s adt paper required reading for every software engineer.
Just a correction and modification of some concepts in OOP !!!
-------
Abstraction is not that concept of showing or providing only the important things or hiding all unnecessary or complex details from the user (the programmer), as everyone thinks !!!
All peoples explained that Abstraction is to provide only what the user can get, in short, to provide only the Important points in the classes that will be instanciated using an Object, and this is unfortunately wrong....
And if it was actually in this sense, the name would have been Only-Important-members or Hidding Data and so on...
Also there is no Pillar named Abstract Data or Data Abstraction !!!
---------
In short, this concept is part of the definition of Encapsulation and not Abstraction, and it is very close to the concept of inheritance rules more than Encapsulation
---------
Linguistically:
Abstraction means intangible or imaginary or virtual or the opposite of Concrete which means tangible, real or active
---------
Programmatically:
It specifically means the Class and the Interface (interface is not available in all programming languages). The important thing is the Class in itself.
And any Class in OOP is considered as a Template, Model, or Map of something in Reality. That thing may be real or imaginary, and as it may be tangible or intangible, it does not matter the Projection and how .... but it matters The Classes that will Ultimately Express an Entity, Component, or Object that we will deal with later....
--------
So Abstraction in OOP will be like that:
Modeling the Real World. and No more than Modelling Definition ..
--------
There are also inactive, intangible, virtual, or Abstract Classes that we call them Class Models or Base Classes, and they are somewhat similar to the Interface.
This type has a directive of type Abstract and it does not accept instanciate with Objects, that is, it has no Objects to represent it (No Instances).
And her task is Only to make a Model or Template for her children's that inherited from and finally can share members from that base Abstract Classe.(Model of SubClasses)
And this technique is also within the definition of the corner Abstraction
And my concept here is focus in modeling and not in the role of the abstract class (because its role in terms of providing only what the sons classes can share as members , this is a part from the corner of rule inheritance)
finally :
Abstract classes is an Abstract Model for a Concrete classes Where this concrete will be a Models for some objects in our Real World...
--------
Interfaces are also a Model where Classes use them in-order to benefit from those members in that Interface..
So, Abstraction OOP is only about these three things ..
------
As for the definition that Peoples explained in the ethernet, it is related to Encapsulation and Inheritance rules and not Abstraction at All ..
-----
Abstraction is the first Step Rule of OOP Pillars wich is the Classes and Interfaces ...
Abstraction is not more than a Modelling ...
maybe virtual methods are also a part of this Cake also ..
----
but in general: A home Construction Engineer cannot start Constructing any home without a Blueprint !!
that's why Abstraction is tied for.. (it's the first Step into OOP)
same thing with Objects (no Classes[MODELLING] no Objects[REAL THINGS] !!)
-----
And thank you for your understanding ...
From the original paper by Barbara Liskov:
[The Meaning of Abstraction] :
"What we desire from an abstraction is a mechanism which permits the expression of relevant details and the suppression of irrelevant details. In the case of programming, the use which my be made of an abstraction is relevant; the way in which the abstraction is implemented is irrelevant."
From: PROGRAMMING WITH ABSTRACT DATA TYPES - Barbara Liskov