"INTERFACES - WHY USE THEM?" 😦 (my reply)
Tags: php, devjournal, laravel, beginners
Published: 2021-08-13 05:29:25

[![Twitter Follow](https://img.shields.io/twitter/follow/cleancodestudio.svg?style=social)](https://twitter.com/cleancodestudio) 

<center>

###### _Would **you** reply?_ 👀

---



## "INTERFACES - WHY USE THEM?"

###### (my 🔥 reply) to a PROVOKING [YouTube] comment 😦

</center>

---

{% user cleancodestudio %}

---

As many of you already know, Clean Code Studio is also a YouTube channel. 


> - **Comments, ever get 'em?** ------> _Tons!_


Now and again a comment will come in that **PROVOKES** the living **HELL** out of me. 


---

> _You know which one I mean?_ 

---

A 🔥 under your a** is lit, your inner Shakespearian rockets from the abyss of your sub-conscience, and **WHAMMMYY!!!**

Before you know it, you've written the greatest monologue since Hamlet's **"To Be Or Not To Be"** spiel.  

---

A while back, one of those <small>**provoking**</small> comments came up.

Check it...I've posted the comment and my Shakespearian monologue of a response below.


<center>

---

### The Comment (That Provoked My Inner Shakespeare)

---

> _"The code after you added the interface was far longer, far more cluttered and far more difficult to follow than it was without the interface. Nothing in this example makes me want to use interfaces. I still don't see any reason to use them at all."_

<small>(Comment made on: [Interfaces - Object Oriented PHP - Lesson 5](https://cleancode.studio/series/object-oriented-php/episodes/5)</small>

</center>

---

### My Reply [To why use interfaces]

###### ("Interfaces, why use them?" - A Shakespearian Monologue) 

---

> That's a **verrryy** reasonable perspective that I respect quite a bit.


> Given this series wasn't an extremely in depth overview covering the reasons behind **WHY** [interfaces](https://cleancode.studio/series/object-oriented-php/episodes/5) and [abstract classes](https://cleancode.studio/series/object-oriented-php/episodes/4) are useful for implementing [design principles](https://cleancode.studio/design-patterns) -- I highly recommend you checkout our [SOLID principles series](https://www.cleancode.studio/series/solid-principles) and specifically the lesson diving into the [Open Closed Principle](https://www.cleancode.studio/series/solid-principles/episodes/2).


Personally, the fact that you challenge adding seemingly needless code is awesome - in my opinion. I'm with you, and whenever possible, opt out of adding needless code if it isn't necessary.


In the lessons offered through out this [object oriented PHP](https://cleancode.studio/series/object-oriented-php), we're covering the very basics. 

We only cover **HOW** to implement concepts like [abstract classes](https://cleancode.studio/series/object-oriented-php/episodes/4) and [interfaces](https://cleancode.studio/series/object-oriented-php/episodes/5).



In this [OOP PHP series](https://cleancode.studio/series/object-oriented-php) we also, very deliberately, avoid many of the **WHY** questions behind using [object oriented](https://cleancode.studio/series/object-oriented-php/episodes/2) concepts like [abstract classes](https://cleancode.studio/series/object-oriented-php/episodes/4) and [interfaces](https://cleancode.studio/series/object-oriented-php/episodes/5).

Here's a quick _"why [interfaces](https://cleancode.studio/series/object-oriented-php/episodes/5)"_ example.

**Example:**

### 1. Imagine we have 3 [classes](https://cleancode.studio/series/object-oriented-php/episodes/1)

```php
Class CsvFile 
{

}

class JsonFile
{

}

class HtmlFile
{

}
```

### 2. Imagine we have a parse function

```php
function parse ($file)
{
    if (is_a ($file, 'CsvFile') {
       // parse csv file
    }
    else if (is_a($file, 'JsonFile')) {
        // parse json file
    }
    else if (is_a($file, 'HtmlFile')) {
         // parse html file
    }
}
```php


> _Note: Any time  we add a [new file type](https://cleancode.studio/series/object-oriented-php/episodes/2), we have to find our parse function and add a new else if conditional to parse the given file type._


### 3. Imagine we have a file [interfaces](https://cleancode.studio/series/object-oriented-php/episodes/5)

```php
interface File 
{
   public function parse();
}

class CsvFile implements File {}
class JsonFile implements File {}
class  HtmlFile implements File {}
```

> _Note: Currently Everything breaks because each of our classes implements a given [interface](https://cleancode.studio/series/object-oriented-php/episodes/5)
 but none actually has the parse method. [Interfaces contractually obligate](https://cleancode.studio/series/object-oriented-php/episodes/5)
 [Classes](https://cleancode.studio/series/object-oriented-php/episodes/1) to implement methods._

 
### 4. Correctly Implement File Interface

```php
class CsvFile implements File 
{
    public function parse() { 
      // parse csv file 
    }
}

class JsonFile implements File {
    public function parse() {
          // parse json file
     }
}

class HtmlFile implements File {
    public function parse() {
         // parse html file
    }
}
```

5. [Refactor](https://cleancode.studio/refactoring) the parse method
```php
function parse(File $file)
{
    $file->parse();
}
```

> _Note: Each class implements the file [interface](https://cleancode.studio/series/object-oriented-php/episodes/5). This forces each [class](https://cleancode.studio/series/object-oriented-php/episodes/1) to Have a parse method. The parse(File $file) function accepts an [instance](https://cleancode.studio/series/object-oriented-php/episodes/2) that implements the _File Interface_.


This means we know that the `$file` passed in can `parse()` even if we don't know exactly how it will parse. 

Each [class](https://cleancode.studio/series/object-oriented-php/episodes/1) implementing the File [Interface](https://cleancode.studio/series/object-oriented-php/episodes/5) is contractually bound to implement their own parse method. Each [class](https://cleancode.studio/series/object-oriented-php/episodes/1) implement the File [Interface](https://cleancode.studio/series/object-oriented-php/episodes/5) defines how it will parse itself. 


In the short term, this does lead to more verbose code. In fact, if you do only have two or three file types and absolutely never need to add any more file types I would recommend sticking with [else if conditionals](https://cleancode.studio/refactoring). 


That being said, if you are unsure how many file types there will be in the future then I recommend using [interfaces](https://cleancode.studio/series/object-oriented-php/episodes/5). 

That way, you only have to [create a new class](https://cleancode.studio/series/object-oriented-php/episodes/1) and [implement the given interface](https://cleancode.studio/series/object-oriented-php/episodes/5). You don't have to [add a new class](https://cleancode.studio/series/object-oriented-php/episodes/5) (SqlFile Class for example) and then update the parse function with another [if else conditional](https://cleancode.studio/refactoring) because you [removed a dependency from your code depending on an interface](https://cleancode.studio/series/solid-principles/episodes/5). 


[Design principles in software](https://cleancode.studio/design-patterns) are recommendations for best practices, but by no means are they absolutes for designing the [cleanest most simplified code](https://cleancode.studio/clean-code).

In the short run, they usually add verbosity - it's up to you as the software engineer to decide if you need to plan for the long run and [implement interfaces](https://cleancode.studio/series/object-oriented-php/episodes/5) and specific [design principles](https://cleancode.studio/design-patterns) that'll [use interfaces](https://cleancode.studio/series/object-oriented-php/episodes/5) to [force functions to be implemented](https://cleancode.studio/series/object-oriented-php/episodes/5) or if this is the last time you'll ever need to [change this code](https://cleancode.studio/refactoring) and [if else conditionals](https://cleancode.studio/refactoring) are the [simplest way to create your software](https://cleancode.studio/clean-code).

Context, attentive care, and intuition based on experience are by far more important than any [design principles](https://cleancode.studio/design-patterns). 

The catch is understanding the [purpose behind interface](https://cleancode.studio/series/object-oriented-php/episodes/5), [abstract classes](https://cleancode.studio/series/object-oriented-php/episodes/4), and the [design principles](https://cleancode.studio/design-pattern) they allow you to implement are necessary to learn if you truly want to [make the best decision based on the context of your problem](https://cleancode.studio/design-patterns).

Sometimes [interfaces are incredible](https://ceancode.studio/series/solid-principles/4) sometimes they are not. Understanding how, why, and when they are valuable or inhibiting gives you the control to make the best decision based on the context of your software.

Understanding [visual simplicity](https://cleancode.studio/clean-code) vs. [longer term architecture requirements as well as design principles](https://cleancode.studio/design-patterns) best fit to meet longer term architecture requirements gives you contextual understanding of your software.

Contextual understanding along with intimate care and a love for simplifying - together - [make great software engineers and helps build world shifting applications](https://cleancode.studio).




---

<center>
[Clean Code Studio](https://cleancode.studio)
☕️ Code Tips
☕️ Career Advice
☕️ Developer Memes
<small>Shiny button, Clean Code 𝗡𝗲𝘄𝘀𝗹𝗲𝘁𝘁𝗲𝗿 👇, juicy dev tips...wanna join?</small> 

[![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/f7hwc3k4pzedr59fnr9r.png)](https://cleancodestudio.paperform.co/)

<small>(Discover [50+ pages] of my personal FAANG interview notes!)</small>
</center>


---

<center>

[Follow @cleancodestudio on Twitter!](https://twitter.com/cleancodestudio)

</center>