---
title: "D8 OOP: Many Entity Types"
date: "2017-05-18T13:08:46+00:00"
summary:
image:
type: "article"
url: "/acquia-cloud-platform/help/91571-d8-oop-many-entity-types"
id: "34b3cae2-41c5-41d7-85a9-13f01a11bd83"
---

Many people, including me, have been blogging about Drupal 8 and its transition to object oriented programming. One question that comes up often is _why?_, given the extra layers of abstraction, complexity, and verbosity that often accompanies that. [Dries wrote a post](http://buytaert.net/why-the-big-architectural-changes-in-drupal-8), answering that question at a high level. In this post, I want to quickly highlight one place, entity types, where the abstractions have what I think to be very obvious and impressive benefits. I believe there are many other places as well; I'm just limiting this blog post to the one.

Let's look at how Drupal 7 implements the _save()_ operation of just four of the _thingies_ in core that need saving: [node\_save()](https://api.drupal.org/api/drupal/modules!node!node.module/function/node_save/7), [user\_save()](https://api.drupal.org/api/drupal/modules!user!user.module/function/user_save/7), [image\_style\_save()](https://api.drupal.org/api/drupal/modules!image!image.module/function/image_style_save/7), and [filter\_format\_save()](https://api.drupal.org/api/drupal/modules!filter!filter.module/function/filter_format_save/7).

If you follow those links, you'll notice that:

*   3 of those 4 are quite lengthy functions, and even image\_style\_save() isn't entirely trivial.
*   They share some similarities. For example, they all write to the database, deal with default values, and invoke at least one hook.
*   There are also some differences. For example, image\_style\_save() receives an array and passes the array to the hook it invokes, whereas the others receive an object (just a data object, not an OOP-style classed object) and pass the object to the hooks, and user\_save() receives (and passes along to the hooks) other information besides the primary object. Also, image\_style\_save() invokes just a single hook: hook\_image\_style\_save(), while filter\_format\_save() invokes either hook\_filter\_format\_insert() or hook\_filter\_format\_update(), and node\_save() and user\_save() invoke _presave_ hooks in addition to the _insert_ and _update_ ones.

Now consider that the function length, pointless differences (which people writing modules that implement those hooks need to keep track of), and duplication of code that's similar, is multiplied to dozens of such thingies in core (and a whole bunch more throughout contrib) and several operations besides save().

In Drupal 8, the official term for these thingies is **entity types**, and the Entity API provides base classes so that each entity type only needs to write the code for the stuff it does that's special for that type. For example, the node entity type is implemented with the Node class, and its only custom save logic is a 1 line [preSave()](https://api.drupal.org/api/drupal/core!modules!node!lib!Drupal!node!Entity!Node.php/function/Node%3A%3ApreSave/8) method and a 3 line [postSave()](https://api.drupal.org/api/drupal/core!modules!node!lib!Drupal!node!Entity!Node.php/function/Node%3A%3ApostSave/8) method.

This results in less code to implement each entity type, and it means that the hooks across all operations of all 40 entity types in Drupal 8 core are consistent.

OOP FTW!  
Acquia Insight Subscription