> This is how I was taught OOP …

That's unfortunate.

"The simplistic approach is to say that object-oriented development is a process requiring no transformations, beginning with the construction of an object model and progressing seamlessly into object-oriented code. …

While superficially appealing, this approach is seriously flawed. It should be clear to anyone that models of the world are completely different from models of software. The world does not consist of objects sending each other messages, and we would have to be seriously mesmerised by object jargon to believe that it does. …"

"Designing Object Systems", Steve Cook & John Daniels, 1994, page 6

https://archive.org/details/designingobjects0000cook

▲

constantcrying 4 days ago | parent [-]

I encourage you to listen to the talk, because it gives a very specific reason why historically that thinking about OOP was so common. Notably it was Stroustrups motivation, to allow exactly that kind of thinking to be implemented in C, which became C++. Simula was developed to allow this structuring.

>While superficially appealing, this approach is seriously flawed. It should be clear to anyone that models of the world are completely different from models of software.

A great line. I just wished it wasn't out shone by all the lectures, tutorials, books which explain OOP by saying "a Labrador is a dog is an animal" and then tell you how this abstraction is exactly what you should be doing.

OOP revisionism is always very surprising, because the only people aware of it are OOP revisionists, the vast majority of developers are completely unaware of it.

	▲	igouy a day ago \| parent \| next [-]
		How can it be revisionism when it's taken from Bjarne Stroustrup's 1988 paper 'What is object-oriented programming?', page 13. 6:03 -- "And what he [Marc LeBlanc] said was for some reason OOP has gotten into this mindset of compile-time hierarchies that match the domain model. …" 6:29 -- "And what he [Marc LeBlanc] is saying is like why are we pushing this? Why is that the idea, right? …" And Stroustrup's starting-point is abstract-data-types not a compile-time-hierarchy — "Consider defining a type 'shape' for use in a graphics system. Assume for the moment that the system has to support circles, triangles, and squares. Assume also that you have some classes … You might define a shape like this … This is a mess." And Stroustrup then says what he's pushing and why and when — "The problem is that there is no distinction between the general properties of any shape … and the properties of a specific shape … The ability to express this distinction and take advantage of it defines object-oriented programming. … The programming paradigm is: Decide which classes you want; provide a full set of operations for each class; make commonlity explicit by using inheritance. … Where there is no such commonality, data abstraction suffices."
	▲	igouy 4 days ago \| parent \| prev [-]
		I listened to the presenter tell us Alan Kay "kind of soured on it [inheritance]" 13:45 The source doesn't say that. I listened to the presenter tell us "… look at what they were actually talking about when they were talking about Smalltalk in the times before they had chance to reflect and say that it [inheritance] didn't work". 14:10 The source doesn't say that. I listened to the presenter tell us "… literally representing in the hierarchy what our domain model is. … They have a Path class and from that Path class they have different shapes derived from it." 14:46 Chapter 20 "Smalltalk-80: The Language and its Implementation" describes how Graphics was implemented in the Smalltalk-80 system — "Class Path is the basic superclass of the graphic display objects that represent trajectories. Instances of Path refer to an OrderedCollection and to a Form. The elements of the collection are Points. … LinearFit and Spline are defined as subclasses of Path. … Class Curve is a subclass of Path. It represents a hyperbola that is tangent to lines … Straight lines can be defined in terms of Paths. A Line is a Path specified by two points." page 400 As they say in the Preface — "Subclasses support the ability to factor the system in order to avoid repetitions of the same concepts in many different places. … subclassing as a means to inherit and to refine existing capability." I listened to the rest of part one.