DEV Community

Cover image for Functional vs Object Oriented vs Procedural programming
Jakub Jabłoński
Jakub Jabłoński

Posted on • Updated on

Functional vs Object Oriented vs Procedural programming

Intro

This is a real life example showing differences of three most common programming paradigms. I will be solving one problem in three different ways.

It's based on the Academind Video
but in the end my solution happened to vary a bit.

Each example will handle form submit, validate user input and print created user to the console. I also added saving error logger.

Html

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <meta http-equiv="X-UA-Compatible" content="IE=edge" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <title>Document</title>
    <!-- <script src="procedural.js" defer></script> -->
    <!-- <script src="oop.js" defer></script> -->
    <!-- <script src="functional.js" defer></script> -->
  </head>
  <body>
    <form id="user-form">
      <div>
        <label for="username">Username</label>
        <input id="username" />
      </div>
      <div>
        <label for="password">Password</label>
        <input id="password" type="password" />
      </div>
      <button type="submit">Submit</button>
    </form>
  </body>
</html>
Enter fullscreen mode Exit fullscreen mode

Simple HTML login form which will have three valid js files in different paradigms.

Procedural programming

Procedural programming is just solving problem step by step. It's completely valid way of coding, but it has many drawbacks when you want your application to scale.

const form = document.querySelector('form')
const logs = []

form.addEventListener('submit', e => {
  e.preventDefault()
  const username = e.target.elements.username.value
  const password = e.target.elements.password.value

  let error = ''

  if (username.trim().length < 3)
    error = 'Username must be at least 3 characters long'
  else if (!password.match(/[0-9]/))
    error = 'Password must contain at least one digit'

  if (error) {
    logs.push(error)
    alert(error)
    return
  }

  const user = {
    username,
    password,
  }

  console.log(user)
  console.log(logs)
})
Enter fullscreen mode Exit fullscreen mode

Simple step by step solution to the problem. But it's not reusable and scalable at all. Although it's completely valid for solving such problem and as you will see it's much shorter than others.

Object Oriented Programming

Object Oriented Programming (OOP) is the closest to the real world so it's quite easy to wrap your mind around. We look at the code dividing it to Object where each one does only it's job.

Useful concept to learn in OOP is SOLID.

// Class responsible only for logging
class Logger {
  static logs = []

  static showAlert(message) {
    this.logs.push(message)
    alert(message)
  }
}

// Class responsible only for validating input
class Validator {
  static flags = {
    minLength: 'MIN-LENGTH',
    hasDigit: 'HAS-DIGIT',
  }

  static validate(value, flag, validatorValue) {
    if (flag === this.flags.minLength) {
      return value.trim().length >= validatorValue
    }

    if (flag === this.flags.hasDigit) {
      return value.match(/[0-9]/)
    }
  }
}

// Class responsible only for creating valid user
class User {
  constructor(username, password) {
    if (!Validator.validate(username, Validator.flags.minLength, 3))
      throw new Error('Username must be at least 3 characters long')
    if (!Validator.validate(password, Validator.flags.hasDigit))
      throw new Error('Password must contain at least one digit')

    this.username = username
    this.password = password
  }
}

// Class responsible only for from handling
class FormHandler {
  constructor(formElement) {
    this.form = formElement
    this.form.addEventListener('submit', this.handleSubmit.bind(this))
  }

  handleSubmit(e) {
    e.preventDefault()
    const username = e.target.elements.username.value
    const password = e.target.elements.password.value

    try {
      const user = new User(username, password)
      console.log(user)
      console.log(Logger.logs)
    } catch (err) {
      Logger.showAlert(err)
    }
  }
}

const form = document.querySelector('form')
new FormHandler(form)
Enter fullscreen mode Exit fullscreen mode

Now you can see what I meant by dividing problem to Objects. FormHandler is it's own class that takes care of form handing. User is another class that takes care of creating user and validates the input using Validator class. If theres an error Logger class is used to display an alert and save the log.

As you can see there is much more code and it looks more complicated... So why would anyone prefer this over Procedura paradigm?

Cool thing is that now we can use it for any similar form just by calling

new FormHandler(new_form)
Enter fullscreen mode Exit fullscreen mode

So it's reusable across every file that includes this script. And also it's easily extendable because everything is divided into blocks that do one thing only (Single responsibility principle).

Functional

Finally my favorite paradigm of all. It's really popular for the time of writing this and quite straight forward.

Note that it doesn't mean that it's better by any means. Which to use is
completely up to you although some paradigms might be better for certain problem.

const FLAGS = {
  minLength: 'MIN-LENGTH',
  hasDigit: 'HAS-DIGIT',
}

// Function that handles validation
const validate = (value, flag, validatorValue) => {
  switch(flag){
    case FLAGS.minLength:
      return value.trim().length >= validatorValue

    case FLAGS.hasDigit:
      return !!value.match(/[0-9]/)
  }
}

// Function that sets submit handler
const setFormSubmitHandler = (formId, onSubmit) => {
  const form = document.getElementById(formId)
  form.addEventListener('submit', onSubmit)
}

// Function that returns values of required fields as object
// In this case it will return {username: "<value>", password: "<value>"}
// It might look scary but keep in mind that it's completely reusable
const getFormValues = (e, ...fields) => {
  const values = Object.entries(e.target.elements)
  const filteredValues = values.filter(([key]) => fields.includes(key))
  return filteredValues.reduce(
    (acc, [key, { value }]) => ({ ...acc, [key]: value }),
    {}
  )
}

// Function that creates valid user
const createUser = (username, password) => {
  if (!validate(username, FLAGS.minLength, 3))
    throw new Error('Username must be at least 3 characters long')
  if (!validate(password, FLAGS.hasDigit))
    throw new Error('Password must contain at least one digit')

  return { username, password }
}

// Function that creates logger object with *logs* and *showAlert* function
const logger = (() => {
  const logs = []
  return {
    logs,
    showAlert: message => {
      logs.push(message)
      alert(message)
    },
  }
})()

// Main function
const handleSubmit = e => {
  e.preventDefault()
  const { username, password } = getFormValues(e, 'username', 'password')

  try {
    const user = createUser(username, password)
    console.log(user)
    console.log(logger.logs)
  } catch (error) {
    logger.showAlert(error)
  }
}

setFormSubmitHandler('user-form', handleSubmit)
Enter fullscreen mode Exit fullscreen mode

As you can see in Functional programming we want to solve the problem using small (ideally pure) functions. This method is also very scalable and functions can be reusable.

Pure function is a function without a side effects that are hard to track.
Pure function should only depend on the given arguments.

Conclusion

There are no better and worse paradigms. Experienced developer can see the advantages of each and chose the best for given problem.

Procedural programming does not say you can't use functions and Functional programing does not prevent you from using Class. These paradigms just help to solve the problem in a way that can be beneficial as the code grows.

Top comments (12)

Collapse
 
efpage profile image
Eckehard

Thank you for the nice writeup!

What about code segmentation in functional code? I know that OO often is a bit verbose, but this often pays back if your project grows.

Collapse
 
jjablonskiit profile image
Jakub Jabłoński

To be honest I'm not sure what you mean by 'code segmentation'.

But yes, OO is very verbose and it's easy to find what you are looking for in code.

Collapse
 
efpage profile image
Eckehard

Sorry for the ambiguous wording. OO can be very helpful to build code segments in larger projects for two reasons:

  1. Classes define a separate a relatively closed environment with own namespace, defined visibility and so on. So, a class or a class hierarchy can be developed without knowing too much about the rest of the task.

  2. Relatively large portions of your code can be isolated, tested and maintainted inside classes. Think of a graphics system, a database adapter, a storage system etc.. This has many advantages for the project:

  3. The code can be reused in other projects

  4. The code is easier to maintain

  5. The class can be used to isolate your application from the physical environment. Example: If a database adapter does all the database handling, you only need to change the adapter to exchang the database system.

Is there any similar mechanism in functional programming?

Thread Thread
 
jjablonskiit profile image
Jakub Jabłoński

You can do the same things as you would in OOP.

Common thing is to just encapsulate logic in separate files. Ex. auth.js exporting functions like login/logout. But not necessarily as a part of any higher object. You can then just import a specific function you need whenever you want without class boilerplate and share and test them as easily as in OOP.

Testing and sharing can also be solved just by keeping related logic within the module folder.

Surely there have to be some ground rules established when working in team. It gives you more freedom but can sometimes fireback because of the amount of ways to structure FP projects.

I think I get your point though, in this simple one file example FP looks like a mess.

Thread Thread
 
efpage profile image
Eckehard

I really appreciate your post, as it is pretty instructive to have a direct comparison. I think it is not helpful to talk about programming paradigms without a task. Here it is clear that it is more a demonstration.

From my experience the three approaches are not mutually exclusive. As classes always are a bit more "expensive" (with respect to code length and brain power), you should use them only where it is necessary or helpful. But to be true, it is never really necessary to use classes, it only may be helpful.

If a class only contains a single function or static data, it´s simply waste of time and memory. OO is no religion, it´s a tool.

So, your code could look like this:

// Class responsible only for creating valid user
class User {
  constructor(username, password) {
    if (username.trim().length < 3)
      throw new Error('Username must be at least 3 characters long')
    if (!password.match(/[0-9]/))
      throw new Error('Password must contain at least one digit')

    this.username = username
    this.password = password
  }
}

// Class responsible only for from handling
class FormHandler {
  logs = []
  constructor(formElement) {
    this.form = formElement
    this.form.addEventListener('submit', this.handleSubmit.bind(this))
  }

  handleSubmit(e) {
    e.preventDefault()
    const username = e.target.elements.username.value
    const password = e.target.elements.password.value

    try {
      const user = new User(username, password)
      console.log(user)
      console.log(this.logs)
    } catch (message) {
        this.logs.push(message)
        alert(message)
    }
  }
}

const form = document.querySelector('form')
new FormHandler(form)
Enter fullscreen mode Exit fullscreen mode

The form handler class might be useful for better reusebility. But here, it only contains one user and one function, so it could easyly substituted by a function, leaving the user as a global definition (which now is encapsulated by the form handler). So, in fact, the user class is the only useful class here.

Pleas don´t misunderstand me, your examples are great as a demonstation. But it also demonstrates a typical misunderstanding: Classes are no value on it´s own. They are only a tool.

By the way: There is no reason not to use functional approaches inside of class functions. And possibly you could write better procedural code, if you try to minimize side effects.

So, from my point of view there are many developers out there, that think they have found the golden calf using one or the other approach. There is nothing like the miracle paradigm that solves all your problems. You will benefit most if you learn to use any approach where it is best suited. If you want to print "Hello world", you even do not need a computer. Use a typewriter instead.

Collapse
 
eljayadobe profile image
Eljay-Adobe

The characteristics I look for in Functional Programming
• first-class functions
• higher-order functions
• code as data
• immutable data
• pure functions (aka referential transparency)
• recursive (specifically: tail recursion)
• manipulation of lists
• lazy evaluation
• pattern matching
• monads (along with currying and partial application)
• separation of behavior from data

For the "What's a monad?" nigh inevitable question: a monad is a function that takes exactly one parameter and returns one result. Using a tuple for the parameter is usually considered cheating. Is is common for a monad that takes one parameter returns another monad, or a monad that returns a result.

A JavaScript example of a monad that returns a monad that returns a monad that returns a result of all the parameters multiplied together:
const cf = (a) => (b) => (c) => (d) => { return a * b * c * d; }

The power of monads is partial application and function composition.

Collapse
 
buondevid profile image
buondevid

Nice summary! Is there an alternative to using classes for OOP?

Collapse
 
alrunner4 profile image
Alexander Carter

ES6 classes are basically just syntax sugar for functions, so you can certainly accomplish the class-centric design with just functions.

Collapse
 
efpage profile image
Eckehard

Yes, but the question is: does this improve your code? If somebody else has to maintain your project, will it help him to understand?

Thread Thread
 
jjablonskiit profile image
Jakub Jabłoński

Both solutions are good imo. Just be consistent with your choice and you will be good

Collapse
 
theschemm profile image
TheSchemm

Yep! Rust can be considered Trait based OOP.

Collapse
 
keyvan_m_sadeghi profile image
Keyvan M. Sadeghi

Great article!