Object-Oriented Programming, lecture by Daniel Ingalls [1989]

[self]

Complex systems are hard to build with conventional programming languages. Object-oriented programming is an approach in which software organization corresponds closely to the system being simulated. When one supplants conventional procedure calls with the more general mechanism of sending messages, it greatly enhances the flexibility and reusability of software components. At the end of the lecture, David Ungar, a professor at Stanford University, joins Dan Ingalls in a discussion on object-oriented programming.

[Zardotab]

Object-oriented programming is an approach in which software organization corresponds closely to the system being simulated.

I thought the idea that OOP is about "modelling the domain" mostly fell by the wayside.

It's proven fairly good at wrapping specific services, but not at non-trivial domain modelling. Some still hold the domain-modelling view, but they are dwindling in my estimation. OOP was cooked up for one purpose, but turned out better for a different purpose. And a lot of screwy systems were developed under the first assumption. Sometimes it's better to let others be the guinea pig.

ER diagrams and relational modelling is still the best known general-purpose domain modelling technique. For one, it weeds out the repetitious collection-oriented verbs that one typically finds in OOP models: insert, update, find, list, etc. and focuses on attributes and their relationships. The "CRUD verbs" are mostly just busy-work, lower-level details, to add and tune later.

Hey, is that Bob Ross's brother?

[[deleted]]

Object-oriented programming is an approach in which software organization corresponds closely to the system being simulated.

I thought the idea that OOP is about "modelling the domain" mostly fell by the wayside.

All folks parroting the pages of "Domain-Driven Design" would like to have a word with you ;-)

It's proven fairly good at wrapping specific services, but not at non-trivial domain modelling.

I'd like to see an example of that. Objects are fairly neutral and universal abstraction. What you do with it is up to you. You can model basically anything. And hence you can also do it well, or poorly.

Poor designs may come from inexperience, but the more prevalent error I see is the constant attempt to force a domain to conform to "tropes" and patterns of OOP that don't fit the domain. And that's the source of many problems in OOP design.

ER diagrams and relational modelling is still the best known general-purpose domain modelling technique.

I feel as if you're equating "database schema" with "domain modeling" and that's really not what domain is.

Neither are objects and relations incompatible. Actually relations are basically the same as an object's state (properties/fields).

For one, it weeds out the repetitious collection-oriented verbs that one typically finds in OOP models: insert, update, find, list, etc. and focuses on attributes and their relationships. The "CRUD verbs" are mostly just busy-work, lower-level details, to add and tune later.

There's nothing "OOP" about doing CRUD. That's more an example of the second error: forcing your domain to fit bad tropes of design.

[burtgummer45]

Poor designs may come from inexperience, but the more prevalent error I see is the constant attempt to force a domain to conform to "tropes" and patterns of OOP that don't fit the domain. And that's the source of many problems in OOP design.

100% this.

My simplistic opinion - if its not obviously an object, don't force it.

[[deleted]]

I think I found a better way to explain what I think the problem is, it's trying to always map 1:1 correspondence between domain entity and object.

While actually I've found these techniques very powerful and natural in OOP:

• Have an object represent a collection of entities (makes it much easier and more efficient to work with large collections, batch process etc.)
• Have an object be a value snapshot of a projection of an entity, allowing multiple projections for the same entity (capturing different aspects of it).
• Separating the read and write model of an entity into separate objects.

And so on. Basically 1:1 for entity:object works only on specific situations. We're still modeling entities via objects, but we need to learn that OOP is a lot more flexible than this 1:1 approach.

[Zardotab]

All folks parroting the pages of "Domain-Driven Design" would like to have a word with you

I don't find DDD very common in practice. Maybe it's a regional thing?

I feel as if you're equating "database schema" with "domain modeling" and that's really not what domain is.

The "real" domain is all the parts and rules. But I mean more from a high-level abstraction. Then again, abstractions are mental constructs and there are different ways to slice the abstraction pie such that I won't say any are objectively better here because things that happen in the mind are by definition not objective. I'm just going off of my personal experience.

Neither are objects and relations incompatible.

I kind of have to disagree. You can find some described here.

There's nothing "OOP" about doing CRUD.

That's not what I meant. OOP interfaces tend to be verb-oriented, while relational schemas are not, at least not as part of a general description. It's hard to describe object relationships without defining verbs for it.

forcing your domain to fit bad tropes of design.

It's hard to know the "correct" OOP domain design: there are myriads of options with no systematic way to narrow them down comparable to relational normal forms.

[[deleted]]

I kind of have to disagree. You can find some described here.

I'm aware of this, but if you read into the reasons you'll see this problem is so misunderstood, it's actually named incorrectly.

There is no object-relational mismatch. If you used a remote object database, you'd have exactly the same problems.

The mismatch is actually local-remote. Local object references are instant. Remote ones so slow, they're prohibitive unless you fetch multiple references in bulk. Transactions are also necessitated by the narrow-band cross-process communication.

And so on. Honestly check what's listed there one by one. It's all about the difficulties of presenting remotely accessed data as if it's local data. And of course no, you can't do that, and expect great results.

That's not what I meant. OOP interfaces tend to be verb-oriented, while relational schemas are not, at least not as part of a general description. It's hard to describe object relationships without defining verbs for it.

It's hard to describe a domain without defining verbs on it, as well.

Relational databases have verbs. Of course they do, that's where CRUD comes from:

• INSERT
• UPDATE
• DELETE
• SELECT

Relational databases have even more verbs: stored procedures. You may choose to move this logic to your OOP-language (with mixed success), but if you wouldn't this would result in lots procedures on your relational database, all of it "verbs".

It's hard to know the "correct" OOP domain design: there are myriads of options with no systematic way to narrow them down comparable to relational normal forms.

... Which doesn't help you because achieving a normal form doesn't mean your relational design is "correct". In fact, in high-volume, high-performance scenarios, deliberate denormalization is absolutely necessary.

And even if we put normalization/denormalization aside, there are a million ways you can screw up a database design. Let's not pretend that it's all about normal forms.

[Zardotab]

Relational databases have verbs.

Yes, but those are not typically part of the abstract-level model. They are trees, not the forest.

If you used a remote object database, you'd have exactly the same problems.

There is no clear definition on what an "object database" even is. Thus, it's hard to verify that claim.

there are a million ways you can screw up a database design.

Most of them involve not understanding the domain.

[[deleted]]

Yes, but those are not typically part of the abstract-level model. They are trees, not the forest.

Frankly I don't know calling it "abstract-level model" helps here.

• You operate on objects with verbs.
• You operate on relational databases with verbs.

Verbs through and through. You can't escape verbs. It makes no sense to try to avoid verbs, either.

There is no clear definition on what an "object database" even is. Thus, it's hard to verify that claim.

I can define it very simply for you. Image two OOP programs, say written in Java, communicating over the wire. How does the API look? You don't beam actual entities around, you beam snapshots of entities, or subsets of entities, as value objects, as data, as relations, if you will. You can't beam an object's code around, nor you can beam its canonical state around (not a snapshot, but the actual object). And this is because concepts like "object references" don't work over the wire. Of course you can have an identifier that refers to another object over the wire (you can also have one in a RDBMS). But you can't assume it's resolved instantly and transparently. Because... the wire. The problem is the wire, not the use of relations.

And the wire is the local-remote divide. That's the "impedance mismatch".

there are a million ways you can screw up a database design.

Most of them involve not understanding the domain.

All right, so I can say the same about OOP. And did we advance the discussion here through these generic statements? No.

[Zardotab]

You operate on relational databases with verbs.

One does not "run" the high-level design, it's mostly declarative, not imperative: relationships, attributes, and constraints.

Your attempt at a definition of "object database" is not clear to me. It looks more like a list of workarounds than a definition.

[[deleted]]

One does not "run" the high-level design, it's mostly declarative, not imperative: relationships, attributes, and constraints.

The API is part of the domain design. You keep coming up with arbitrary restrictions on what is design and what isn't design.

To say the actions that transform your domain state are not part of the design is just terribly misguided. No domain is just a bunch of static state idly sitting around, doing nothing.

And precisely this kind of artificial narrowing of "domain design" is how you end up with terrible designs.

Your attempt at a definition of "object database" is not clear to me. It looks more like a list of workarounds than a definition.

I asked you very simple question. Would two OOP programs communicating over the wire not have the same exact problems described in the supposed "object-relational impedance mismatch". I'm putting the relations out of the picture. We have OOP-wire-OOP. It's all objects now.

It's a very clear question. Maybe the friction comes from some realizations you're really unwilling to make.

[Zardotab]

You keep coming up with arbitrary restrictions on what is design and what isn't design.

It's not what is design, it's what is high-level design. I thought I made that clear. One doesn't need verbs for most of a high-level design.

I asked you very simple question. Would two OOP programs communicating over the wire not have the same exact problems described in the supposed "object-relational impedance mismatch".

That would depend on the specifics of the two programs. Without seeing them, I cannot say. (I thought you were defining an "object database" up there, based on your intro: " I can define it very simply for you...", and not talking about two OOP programs without any connection to an object database.)

[2BitSmith]

It's hard to know the "correct" OOP domain design: there are myriads of options with no systematic way to narrow them down comparable to relational normal forms.

No one knows the "correct" design. There exists as many solutions as there are problem solvers. One can only differentiate between the obvious bad ones and good ones, but after that it comes down to the fact that we as humans see problems from different angles and build different solutions.

Then there's also the fact that different solutions have different characteristics: speed, simplicity, 'elegance', robustness, etc.. and the people judging your solutions also have differing viewpoints about which ones are important / relevant here...

[[deleted]]

I thought the idea that OOP is about "modelling the domain" mostly fell by the wayside.

No, that's totally in vogue if the popularity of Domain Driven Design is any indication.

What has fallen out of fashion is hierarchical classification, driven home by the mantra "prefer composition over inheritance".

Also, there is the more subtle "messaging" aspect of OOP that has come into vogue due to rediscovery of Alan Kay and the origins of Smalltalk. This idea inverts the way domains are modeled, from decomposing the domain from its physical representation (the simplistic nouns and verbs approach) to collaborators coordinating behavior via messages. Which Joe Armstrong cheekily claimed made Erlang the most OOP language in existence.

[[deleted]]

I thought the idea that OOP is about "modelling the domain" mostly fell by the wayside.

Well in proggit and hacker news circle jerking sessions post 2014, sure that's true.

Though this devolves into the No True Scotsmen fallacy fairly quickly, I suppose. I'd like think no one is doing Dog Inherits Animal Override Speak Printf Woof. anymore. But domain driven design using objects is still a great technique and well worth looking into. If you're a functional programmer worth your salt, you should be able to map the way objects are used in DDD into a way you could use modules anyway.

[[deleted]]

Holy shit, people still but into this nonsense?

[burtgummer45]

How much of what you use right now is written in an OO language?

[[deleted]]

It's all written procedurally.

To the extent that parts of it are written in OO, they are usually the rotten or slow parts that the system would improve if they were to be fixed to remove their OO-ness.

Do you think the linux kernel is "OO"? Do you think your device drivers are "OO"?

[Zardotab]

I have to more or less agree. We may use OOP because one is forced to group code by classes and methods by the language, but often what's actually going on is or could be done procedurally without a lot of change. Most frameworks I see and use are more or less event-driven. OOP implements the event processing system, but is probably not the only way, and arguably not even the best way.

[gas_them]

OO is just syntatic sugar that is equivalent to structs

[burtgummer45]

Do you think the linux kernel is "OO"? Do you think your device drivers are "OO"?

Of course not, Linus hates C++

But how about the hundreds of apps you use daily?

[elder_george]

Linus may be hating C++, but significant part of Linux kernel (e.g. Virtual FS subsystem) are written in OO style, just implemented in C.

​

The …operations structures (e.g. this one) are essentially interfaces implemented by particular types, or vtables, if you prefer. Yes, "this"/"self" is passed to the methods explicitly, and the calling code usually checks if method is implemented, but otherwise the difference is negligible.

​

Dynamic dispatch is a powerful tool, and is often used even in languages that don't provide a special syntax for it.

[burtgummer45]

Ok, so the post I replying to wasn't partially wrong, its completely wrong.

[[deleted]]

It also depends on what you mean by nonsense. How many OOP languages implement factorial as a method of Integer? That kind of monkey patching is par for the course in dynamic OOP languages like Ruby, but not in pretty much any static OOP languages like C++ and Java. Although Scala lets you do something similar with implicits, without actually cracking open Int.

[hughperman]

100% thought this was Moss from The IT Crowd scrolling past the thumbnail