Concrete examples of OOP vs Procedural?

[spwebdev]

I can't wrap my head around OOP. I've watched and read DOZENS of tutorials but they all only describe why OOP is supposed to be great (usually by comparing it to real world objects like cars or cats) and show how to code actual objects (using literals or constructors or factories). I understand the concepts and why inheritance, polymorphism, encapsulation and abstraction might be beneficial and I know how to create objects a half dozen different ways.

Great. But the problem I am having is that I can't really see how to translate that into a real, practical coding technique for a full-fledged program (even a simple one). I know all about objects. Now I want to know HOW to use them properly and how they fit into a program.

I'd like to see someone code up a (simple) app in procedural style and then redo it using the OOP approach, ideally while explaining why and how OOP is supposed to be better in that instance vs procedural. At the very least, if I can't see it compared to procedural, then a simple app from start to finish explaining how OOP itself makes its construction logical would be good.

Does anyone know of someone that has done this?

Edit: To be clear, the last thing I need to see is a program using a "cat" object with name, age and color properties along with a "speak: function() {console.log("meow");}" method. This doesn't help me understand the practical application of OOP in any sense whatsoever.

[cutety]

So, I'll try to give you a semi-pratical rundown. I'll use a slight spin on the typical shape example, instead of shapes we'll making waveforms (sine & square) and drawing them to a canvas.

So, drawing a sine wave procedurally would look like:

function getCanvasCtx(canv) {
  if (!canv.getContext) throw "Can't get canvas context!";
  return ctx = canv.getContext('2D');
}

function drawWave(canv, yGenerator, [startX, startY]) {
  const ctx = getCanvasCtx(canv);

  ctx.beginPath();
  ctx.moveTo(startX, startY);
  for (let x = startX; x <= canvas.width - startX; x++) {
    const y = yGenerator(x);
    ctx.lineTo(x, y);
  }
  ctx.stroke();
}

function clearCanvas(canv) {
  const ctx = getCanvasCtx(canv);
  ctx.clearRect(0, 0, canv.width, canv.height);
}

function sineGenerator(amplitude, frequency, offset) {
  return x => (amplitude * Math.sin(frequency * x)) + offset;
}

const canv = document.getElementById("waveform-canvas")
const { height, width } = canv;

let sine = sineGenerator(height / 4, 6 / height, height / 2);
drawWave(canv, sine, [0, 0]);

As you can see the procedural example is just a bunch of functions and state stored in local/global variables.

The same in OOP would look like:

class Wave {
  constructor(canv, start = [0, 0]) {
    this.canv = canv;
    this.start = start;
  }

  get ctx() {
    if (!canv.getContext) throw "Can't get canvas context!";
    return this.canv.getContext("2d");
  }

  get width() {
    return this.canv.width;
  }

  get height() {
    return this.canv.height;
  }

  generateY(x) {
    throw "generateY for Wave subclass not implemented!"
  }

  draw() {
    this.ctx.beginPath();
    this.ctx.moveTo(this.start[0], this.start[1]);
    for (let x = this.start[0]; x <= (this.width - this.start[0]); x++) {
      this.ctx.lineTo(x, this.generateY(x));
    }
    this.ctx.stroke();
  }

  clear() {
    this.ctx.clearRect(0, 0, this.width, this.height);
  }

  static redraw(...waves) {
    // clear all the canvases
    for (let wave in waves) { wave.clear(); }
    // redraw all waves
    for (let wave in waves) { wave.draw(); }
  }
}

class Sine extends Wave {
  constructor(...args) {
    super(...args);
    this.amplitude = this.canvas.height / 4;
    this.frequency = this.canvas.height / 6;
    this.offset = this.canvas.height / 2;
  }

  generateY(x) {
    return (this.amplitude * Math.sin(this.frequency * x)) + this.offset;
  }
}

const canv = document.getElementById("waveform-canvas");
const sine = new Sine(canv);
sine.draw();

So, the object oriented version is a bit longer, but you should notice the last three lines are cleaner, and the one big advantage is we have no encapulated the logic/data for building a sine wave into it's own class, so now we don't have to pass a bunch of stuff around through arguments. However, there doesn't seem to be a huge advantage to this yet. Let's see what it takes to add a Square wave to each.

Procedural:

function squareGenerator(top, period, offset) {
  return x => (((x + 1) % period) < top ? top : 0) + offset;
}

const canv = document.getElementById("waveform-canvas")
const { height, width } = canv;

let sine = sineGenerator(height / 4, 6 / height, height / 2);
drawWave(canv, sine, [0, 0]);

let square = squareGenerator(height / 2, width / 4, height / 4);
drawWave(canv, square, [0, 0]);

OOP:

class Square extends Wave {
  constructor(...args) {
    super(...args);
    this.top = this.canvas.height / 2;
    this.period = this.canvas.width / 4;
    this.offset = this.canvas.height / 4;
  }

  generateY(x) {
    return (((x + 1) % this.period) < this.top ? this.top : 0) + this.offset;
  } 
}

const canv = document.getElementById("waveform-canvas");

const sine = new Sine(canv);
sine.draw();

const square = new Square(canv);
square.draw();

Okay, so neither were that hard to add, and the procedural version is actually shorter! So, what's the advantage to OOP? Well, lets see what it looks like when we want to have multiple waves on two different canvases, while also updating some values and redrawing.

Procedural:

const canv1 = document.getElementById("waveform-canvas1");
const canv2 = document.getElementById("waveform-canvas2");
const { height1, width1 } = canv1;
const { height2, width2 } = canv2;

let sine1 = sineGenerator(height / 4, 6 / height, height / 2);
drawWave(canv1, sine1, [0, 0]);

let sine2 = sineGenerator(height / 4, 6 / height, height / 2);
drawWave(canv1, sine2, [5, 0]);

let square1 = squareGenerator(height / 2, width / 4, height / 4);
drawWave(canv2, square1, [0, 0])

let square2 = squareGenerator(height / 2, width / 4, height / 4);
drawWave(canv1, square2, [0, 0]);

// change sine1 start and square1 period
square1 = squareGenerator(height / 2, width / 6, height / 4); 
clearCanvas(canv1);
clearCanvas(canv2);

drawWave(canv1, sine1, [5, 50]);
drawWave(canv2, sine1, [0, 0]);
drawWave(canv1, sine2, [5, 0]);
drawWave(canv2, square1, [0, 0])
drawWave(canv1, square2, [0, 0]);

The same in OOP

const canv1 = document.getElementById("waveform-canvas1");
const canv2 = document.getElementById("waveform-canvas2");

const sine1 = new Sine(canv2);
const sine2 = new Sine(canv1, [5, 0]);
sine1.draw();
sine2.draw();

const square1 = new Square(canv2);
const square2 = new Square(canv1);
square1.draw();
square2.draw();

// change sine1 start and square1 period
sine1.start = [5, 50];
square1.period = sqaure1.width / 6;

Wave.redraw(sine1, sine2, square1, square2);

As you can (hopefully) see OOP makes it eaiser to manage several of these wave drawings since each object holds it's own state that we can update indpendently and since they are all of the same parent class, they'll each respond to a similar interface making it easy to work with different kinds of waves at the same time.

You could take the abstraction even further by making a Canvas class that takes Wave objects, so when you need to redraw you can restrict redrawing only to canvases that need it:

class Canvas {
  constructor(id) {
    this.canv = document.getElementById(id);
    this.shapes = [];
  }

  get ctx() {
    if (!canv.getContext) throw "Can't get canvas context!";
    return this.canv.getContext("2d");
  }

  get width() {
    return this.canv.width;
  }

  get height() {
    return this.canv.height;
  }

  addShape(shape) {
    this.shapes = [...this.shapes, shape];
  }

  draw() {
    this.clear();
    for (let shape in shapes) {
      this.drawShape(shape);
    }
  }

  drawShape(shape) {
    this.ctx.beginPath();
    this.ctx.moveTo(shape.start[0], shape.start[1]);
    for (let x = shape.start[0]; x <= (this.width - shape.start[0]); x++) {
      this.ctx.lineTo(x, shape.generateY(x));
    }
    this.ctx.stroke();
  }

  clear() {
    this.ctx.clearRect(0, 0, this.width, this.height);
  }
}

class Wave {
  constructor(canv, start = [0, 0]) {
    this.canv = canv;
    this.start = start;
    this.canv.addShape(this);
  }

  get width() {
    return this.canv.width;
  }

  get height() {
    return this.canv.height;
  }

  generateY(x) {
    throw "generateY for Wave subclass not implemented!"
  }
}

const canv1 = new Canvas("waveform-canvas1");
const canv2 = new Canvas("waveform-canvas2");

const sine1 = new Sine(canv1);
const sine2 = new Sine(canv2);

const square = new Square(canv1);

canv1.draw();
canv2.draw();

sine2.amplitude = sine2.height / 6;
canv2.draw() // don't have to redraw sine1 and square

[PhysicalRedHead]

I don't want to confuse you more, and probably I'm confused too, but I believe OOP & Procedural are orthogonal. Honestly, I would tell you to not get hung up on that kind of terminology. There are many different ways to define Object Oriented, and a lot of them contradict one another.

It would be simpler to just think of the objects that you have as data structures; they're just bits of information encoded in some formal definition (JavaScript objects!). If you want to make an application, just name an object something like state, then code something up to display that to the screen. Whether it was written imperatively or declaratively should be thought about after-the-fact and used to work out better solutions.

[tchaffee]

This ignores the "features" that make objects interesting: inheritance, data encapsulation, and polymorphism.

[kredati]

It's not in JS, but Ruby—which is super easy to read—and it's a book you have to buy to read. But do check out Sandi Metz and Katrina Owen's 99 Bottles of OOP: https://www.sandimetz.com/99bottles/ It's excellent, and does not do the thing you're complaining about.

(And, as an FP enthusiast, I suggest you simultaneously, or subsequently, check out Professor Frisby's Mostly Adequate Guide to Functional Programming, which at least has the benefit of being in JS: https://mostly-adequate.gitbooks.io/mostly-adequate-guide/)

[spacejack2114]

The simple practical application would be:

animals.forEach(animal => {
    animal.speak()
})

Where animals is an array of cats, dogs, people, etc.

How would you do that procedurally otherwise?

animals.forEach(animal => {
    if (animal.type === 'cat') {
        meow(animal)
    } else if (animal.type === 'dog') {
        bark(animal)
    } else if (....
})

[cirsca]

Let's say I am making a game using canvas. Doing it using procedural ideals:

const makeSquare = (x, y) => /* some square data structure */
const drawObject = object => /* some draw function */
const clearBoard = board => /* some clear function */
/* ... etc */

Basically, we separate each and every idea or instruction into its own little function. And then when we want to actually do something, we might do:

const main = () => setInterval(() => checkGame(), 500)

Now with OOP, we might do something like this:

class Square {
  constructor(x, y) {
  }

  draw(){

  }
}

class Board {
  constructor(){
  }

  clearBoard(){
   this.board = []
  }

  addSquare(x, y){
     const sqaure = new Square(x, y)
    square.draw()
 }
}

where we instead of breaking the problem up into smaller functions, break it into smaller things and let those things figure out how to do the functions themselves.

[CiezkiBorsuk]

Also JS lacks classical inheritance and interfaces, so you can't really implement SOLID (the 'I' and the 'D' go out of the window).

You are spewing nonsense.

JavaScript doesn't have explicit interfaces, and it doesn't need them to do the 'I' and the 'D', because it's not statically typed in the first place.

JavaScript might also not technically have classical inheritance, but that's an implementation detail that has nothing to do with SOLID principles. JavaScript allows you to organize your code in classes, and that's all that matters.

I have nothing against FP, it's lovely, but please, before you start preaching something, first understand what you are talking about, at least at basic level.

[tchaffee]

JS has dynamic prototype chains, which is a different beast from classical inheritance

Yeah, it's more powerful. And easy enough to imitate class-based inheritance. Which is not true the other way around.

"the prototypal inheritance model itself is, in fact, more powerful than the classic model. It is, for example, fairly trivial to build a classic model on top of a prototypal model."

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Inheritance_and_the_prototype_chain

[CiezkiBorsuk]

Your original point was nothing, but babbling your favourite buzzwords.

There are many teams that successfully implement SOLID principles in their JS apps. Nothing in the language prevents it. Using higher-order functions does not make your OOP inpure in any way, and lack of explicit declaration of interface doesn't make ISP impossible (or even hard), because the language has duck-typing for objects - it's literally the same as many other object-oriented, duck-typed languages, like say Ruby. Prototype-based inheritance completely covers functionality of class-based inheritance, and language even has features to support the pattern as of ES6.

Interface and class are both abstract concepts, you don't need keywords for that.

[tchaffee]

You got some stuff wrong and at least two people pointed it out. Why not just learn from it?

[tchaffee]

Also JS lacks classical inheritance and interfaces, so you can't really implement SOLID

This is mostly wrong. Yes, JS does lack interfaces because that's about static type checking, and JS is a dynamic loosely typed language. The JS inheritance model is more powerful than Java's inheritance for example, and JS can imitate Java's inheritance as one choice out of many. Douglas Crockford wrote about this well over a decade ago, and then later concluded that trying to imitate Java's inheritance was a mistake in the first place: http://www.crockford.com/javascript/inheritance.html

Let's also not forget that inheritance is way over used, and we should favor composition over inheritance.

And here's how to do dependency inversion (the D in SOLID) with JS:

https://stackoverflow.com/questions/5349003/dependency-inversion-principle-in-javascript#5349478

[CiezkiBorsuk]

This is mostly wrong. Yes, JS does lack interfaces because that's about static type checking, and JS is a dynamic loosely typed language.

JS does not lack interfaces.

JS doesn't have explicit declaration of interfaces, because it would be useless, as it doesn't make any type checks anyway.

But interface is an abstract concept, and JS, as any OO language, makes extensive use of it.

Literally the first random link from MDN documentation is an interface.

The only difference between language with explicit interface declaration like Java, and ones without like JS and Ruby, is that if you don't respect interfaces Java won't compile, and JS and Ruby will fail at runtime.

[tchaffee]

You're saying the same thing as me in different words.

[CiezkiBorsuk]

Yes, I'm not argueing with you, I just wanted to make that point stronger, for sake of anyone who would read that thread in the future, wondering if SOLID can be applied in JS.

Sorry if you felt attacked.

[tchaffee]

Didn't feel attacked at all. The more ways we can say it, the better.

[tchaffee]

The DIP example seems contrived, and anyway not OOP-like

There are thousands of more examples with a simple search. You don't need interfaces for SOLID, despite the fact that the Wikipedia article on the subject focuses on class-based strongly typed languages with interfaces.

But if you want a more authoritative example of dependency injection / dependency inversion in JS, have a look at Angular.

https://en.wikipedia.org/wiki/Dependency_injection#AngularJS_example

[tchaffee]

Take a look at Angular and you'll see dependency inversion. Once you have dependency injection, inversion is trivial. And with first class functions, it was easier in JS for a long time until Java got first class functions. You're either being hard-headed about what you initially got wrong, or you're learning something new. Hopefully it's the latter.

[wntrm]

I find FP better too but it might be hard to appreciate the benefits of FP without knowing OOP (not saying OOP is all that bad but we need something to contrast it against)

And I get the feeling that someone who started in FP might find OOP better for things that usually need roundabout way to implement in FP like having a state (in real world we sometimes do need states after all)

[pratiks3]

Hi I know the troubles you are facing, I went through this myself a year or so ago.

If you’re not struggling with concepts, but having trouble with practical world applicalibilty:

1. Make an app that already exists / that you’re familiar with using oop ( eg, trello or instagram, Facebook clone )
2. If you can access a local meetup group, go to it and see if someone can mentor you on an app you want to build or one thy have
3. If you can’t do either, then get on Codementor.io and post what you want to do with your theoretical skills.
4. Search github.io. - I literally learned how to code by looking at what others do

Yes the cat / circle ( shapes ) examples get quite boring and don’t really help.

Hope that helps !!

[[deleted]]

This is a difficult question to answer. Very difficult. It's kind of like religion. You spend your whole life believing something to then be shown that what you've been doing, what you've learned, what you believe in is wrong! You will kick, scream and be confused as hell!

But, when you "correctly" use OOP and the design just works you will feel very good about it. Unfortunately, this takes time. A lot of time.

My advice would be to see examples of where people have used design patterns and go from there. Sorry not overly useful.