Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Can We Have OOP Without Classes?

DZone's Guide to

Can We Have OOP Without Classes?

Popular MVB Yegor Bugayenko discusses whether classes are really needed for object orientation.

· Java Zone ·
Free Resource

Take 60 minutes to understand the Power of the Actor Model with "Designing Reactive Systems: The Role Of Actors In Distributed Architecture". Brought to you in partnership with Lightbend.

I interviewed David West, the author of the Object Thinking book, a few weeks ago, and he said that classes were not meant to be in object-oriented programming at all. He actually said that earlier; I just didn't understand him then. The more I've thought about this, the more it appears obvious that we indeed do not need classes.

Battleship Potemkin (1925) by Sergei M. Eisenstein
Battleship Potemkin (1925) by Sergei M. Eisenstein

Here is a prototype.

Let's say we have only types and objects. First, we define a type:

type Book {
  void print();
}

Then we create an object (pay attention; we don't "instantiate"):

Book b1 = create Book("Object Thinking") {
  String title;
  Book(String t) {
    this.title = t;
  }
  public void print() {
    print("My title: " + this.title);
  }
}

Then we create another object, which will behave similarly to the one we already have but with different constructor arguments. We copy an existing one:

Book b2 = copy b1("Elegant Objects");

Libraries will deliver us objects, which we can copy.

That's it.

No implementation inheritance and no static methods, of course. Only subtyping.

Why not?

Learn how the Actor model provides a simple but powerful way to design and implement reactive applications that can distribute work across clusters of cores and servers. Brought to you in partnership with Lightbend.

Topics:
static methods ,object-oriented programming ,objects ,constructor ,inheritance ,object-oriented ,prototype ,programming

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}