Object Oriented Programming
Tags: oop, php, beginners, webdev
Published: 2018-12-15 10:09:23

---
title: Object Oriented Programming 
published: true
description: Object-oriented programming in its core is all about sending messages and responding to them. In my opinion, this is best described by Tell don't ask principle.
tags: oop, php, beginners, webdev
canonical_url: https://sasablagojevic.com/object-oriented-programming
cover_image: https://sasablagojevic.com/img/front/ooppie.jpg
---
<em>Originally published at <a href="https://sasablagojevic.com/object-oriented-programming">sasablagojevic.com</a></em>

The aim of this article is to break down the major concepts of OOP for newbie developers in a more digestible format and I hope they will have a better understanding of the Object-Oriented Paradigm after reading it.  

------

<p>We all know the majority of newbie developers prefer to get their hands dirty than to read so I'll try to cut the bullsh*t to the minimum. When I was a newbie to programming myself and when I was first delving into the world of OOP, learning what a <em>Class</em> is and what an <em>Object</em> is was the easy part. Applying them to the real world problems I was trying to solve was the tricky part.</p>
<ul>
<li>How do I structure my code?</li>
<li>What should my <em>Class</em> be concerned with?</li>
<li>Should I split this <em>Class</em> into more?</li>
<li>How should the public API of my <em>Class</em> look like?</li>
<li>How should the methods be named in conjunction with the <em>Classes</em>' name?</li>
<li>Should this method be static?</li>
</ul>
<p>Those were all the questions that I asked myself.</p>
<p>Since I'm a self-taught developer, I lacked some theoretical knowledge, so I decided to read more about OOP and design patterns.&nbsp;Previously I have been doing things more intuitively and it has done me well. I was on the right track, I've advanced in my career and nobody complained about my code, on the contrary, but there comes a time when you need to get a deeper understanding,&nbsp;how things "work under the hood" to take both your knowledge and career to the next step.&nbsp;</p>
<p>The aim of this article is to break down the major concepts of OOP for newbie developers and I hope they will have a better understanding of the Object-Oriented Paradigm after reading it. It is intended as a cheat sheet they can come back to and freshen up their knowledge and not only them, myself included ;)&nbsp;</p>
<h2>All Roads Lead to Rome</h2>
<p>To get a better understanding of OOP and what issues people were trying to solve with it, we will briefly go over some of the&nbsp;different and most common programming paradigms. While most of&nbsp;the&nbsp;modern languages&nbsp;have a multi-paradigm approach at some point in their lifetime they might not have had. It has been an iterative process to come where we are today, it is a long road from Assembler to PHP.</p>
<h3>Programming paradigms</h3>
<ul>
<li><strong>Imperative</strong>
<ul>
<li>&nbsp;Procedural</li>
<li>...</li>
</ul>
</li>
<li><strong>Structured&nbsp;</strong>
<ul>
<li>Object-oriented</li>
<li>...</li>
</ul>
</li>
<li><strong>Declarative</strong>
<ul>
<li>Functional</li>
<li>...</li>
</ul>
</li>
</ul>
<p>In&nbsp;<strong>imperative programming</strong>,&nbsp;we give instructions to the computer what to do and in which order to do it. Every time we tell the computer to remember something by storing it in a variable we are using&nbsp;<em>statements</em> to change the <span style="text-decoration: underline;">global&nbsp;state</span> of the program. You can already see how this could get messy in big programs with lots of developers because all of them are directly changing the global state the chance of making bugs and overriding data is high.</p>
<p><strong>Procedural programming</strong>, although often used as a synonym for imperative programming, is actually an extension of the imperative paradigm. In procedural programming, we group aforementioned instructions into <span style="text-decoration: underline;">procedures</span>, also known as <a title="Subroutines" href="https://en.wikipedia.org/wiki/Subroutine" rel="noopener">subroutines</a> or functions. <span style="text-decoration: underline;">Procedures</span> are just a set of instructions, a modular unit, that we can reuse in our program just by&nbsp;calling it without having to rewrite the specific steps all over again. But at this point, you already know this ;) Procedural programming brought us the concepts of&nbsp;<a title="Blocks" href="https://en.wikipedia.org/wiki/Block_(programming)">blocks</a> and&nbsp;<a title="Scope" href="https://en.wikipedia.org/wiki/Scope_(computer_science)" rel="noopener">scopes</a>, which gave us a new type of state, <em>local</em>. Local state means that is valid only in the context of that specific procedure.</p>
<p>As we can see the focus of procedural programming is to break down the computer instructions into variables&nbsp;and subroutines/functions, whereas in <strong>object-oriented programming</strong> it is to break it down into <strong>objects</strong>.</p>
<p>Objects expose their behaviour through <span style="text-decoration: underline;">methods</span>&nbsp;(class/object functions) and have their own internal state in form of <a title="Properties" href="http://php.net/manual/en/language.oop5.properties.php" target="_blank" rel="noopener">members/attributes</a>. Both the methods and attributes may or may not be accessible to the outside world depending on their <a title="Attribute and Method visibility" href="http://php.net/manual/en/language.oop5.visibility.php" target="_blank" rel="noopener">visibility</a>.&nbsp;</p>
<p>So you see, both <em>procedural</em> and <em>object-oriented</em> paradigms&nbsp;were trying to solve the same issues: the issue of mutating the global state and breaking down complex tasks into smaller modular units (subroutines/functions vs. objects), in their own respective ways.</p>
<p>Object-oriented programming in its core is all about <span style="text-decoration: underline;">sending messages and responding to them</span>.</p>
<blockquote>
<p>In procedural programming, a process is expressed in one place in which a series of instructions are coded in order. Whereas in OO, a process is expressed as a succession of messages across objects. (David Chelimsky in Single Responsibility Applied to Methods)</p>
</blockquote>
<p>In my opinion, this is best described by the&nbsp;<a title="Tell Don't Ask" href="https://martinfowler.com/bliki/TellDontAsk.html" target="_blank" rel="noopener"><em>Tell don't ask</em></a> principle.&nbsp;</p>
<blockquote>
<p>Don't ask for the information you need to do the work; ask for the object that has information to do the work for you. (Allen Hollub - Hollub on Patterns)</p>
</blockquote>
<p>Let's expand on this a bit in layman's terms. Contrary to procedural and functional paradigms where we would pass data from a function to function, manipulate it and return it, in OOP we want the object that encapsulates that data (has it in its internal state) to do the manipulation for us. We achieve that by sending it a <em>message.</em>&nbsp;After receiving our message the object will determine based on its internal knowledge and methods what it will give us as a <em>response</em>.&nbsp;</p>
<p>In even simpler terms, <em>messages</em> would be our method calls and <em>responses</em> the data those methods return. Bear in mind that methods can be void, meaning they don't return any data, they just change the internal state of the object, but you get the gist of it.</p>
<p>So to put that in practical terms it would look something like this. *Disclaimer* This is a highly simplified example just for illustrative purposes.</p>

```php
function mark_as_read(array $email) 
{
    $email['is_read'] = 1;
    return $email;
}

$email = [
    "from" => "Marry Doe",
    "to" => "John Doe",
    "subject" => "Dear John",
    "body" => "I\'m leaving you"
];

mark_as_read($email);

// vs.

class Email {

    protected $from;

    protected $to;

    protected $subject;

    protected $body;

    protected $isRead;

    public function __constructor(string $from, string $to, string $subject, string $body)
    {
        $this->from = $from;
        $this->to = $to;
        $this->subject = $subject;
        $this->body = $body;
    }

    public function markAsRead(): Email
    {
        $this->isRead = 1;
        return $this;
    }

    public function isRead(): bool
    {
       return $this->isRead === 1;
    }
}

$email = new Email("Marry Doe", "John Doe", "Dear, John", "I'm leaving you.");

$email->markAsRead();
```

<p>There is a good metaphor by one of the fathers of OOP Allan Kay, he says that&nbsp;<em>objects</em> are like cells in our bodies, small self-contained units that make up our human being.</p>
<p>Ok, just because we know now how to cram functions and data in a class does not mean we know OOP, let's make everything a class now is a common newbie pitfall. There are a few more things we need to keep in mind!&nbsp;:D But before talking further let's just briefly go over the last two paradigms.</p>
<p>In contrast to the imperative paradigm, the <strong>declarative</strong> paradigm tells the computer what we want, not the steps how to get it. A perfect example of a declarative programming language is <strong>SQL</strong>.&nbsp;&nbsp;</p>
<p><strong>Functional paradigm</strong> is a subset of the declarative paradigm and it uses declarations/expressions unlike statements in the imperative family, but like its counterparts, it also tries to solve this issue of manipulating the global state. In functional programming, programs are thought of as a collection of pure functions. <a title="Pure functions" href="https://en.wikipedia.org/wiki/Pure_function" target="_blank" rel="noopener"><span style="text-decoration: underline;">Pure functions</span></a> are functions which take input and always return new values. They never have side effects, they never mutate the state and they are always expected to give the same result given the same input. So in the functional paradigm, the state is&nbsp;<span style="text-decoration: underline;">immutable</span>.</p>
<p><a title="Programming Across Paradigms" href="https://twitter.com/AnjanaVakil" target="_blank" rel="noopener">@AnjanaVakil</a> puts it more eloquently in her <a title="WCZG 2017 - Programming Across Paradigms" href="https://2017.webcampzg.org/talks/programming-across-paradigms/">Programming Across Paradigms keynote at WebcampZG 2017</a>, I recommend you watch it.</p>
<h2>Basic OOP Principles</h2>
<h3><strong>Single Responsibility</strong></h3>
<p><span style="text-decoration: underline;">A class should only be concerned and handle one aspect of a complex problem we are trying to solve</span>. It doesn't mean that a class should literally have just one responsibility, it's not a function for Pete's sake, it can have multiple but they all need to be a part of <strong>one</strong> broader task. When we say <em>single responsibility</em> we are talking from the context of our business/domain logic. For example, let's look at the PHP's built-in <em>SplFileObject</em>, that class is responsible for:</p>
<ul>
<li>reading the file,</li>
<li>writing to the file,</li>
<li>checking if the file exists,</li>
<li>checking if the given path is a file or directory, etc.</li>
</ul>
<p>But all these actions are under the umbrella of one broader task, <em>interacting with the files</em>.</p>
<h3><strong>Abstraction</strong></h3>
<p>Abstraction, in this case, is an umbrella term for <em>Interfaces</em> and <em>Abstract Classes</em>. In PHP those are the two main abstraction mechanisms.&nbsp;</p>
<p><strong><a title="PHP - Interfaces" href="http://php.net/manual/en/language.oop5.interfaces.php" rel="noopener"><span style="text-decoration: underline;">Interfaces</span></a> are contracts for behaviour</strong>. We use them to define the public API of a class, and ensure that when a message is sent to a class instance (object) which implements that interface, the object will always respond according to the definition otherwise the program will fail. In other words, the interface defines the methods a class needs to implement in order for our program to work otherwise it will break.</p>
<ul>
<li>Interfaces can't be instantiated</li>
<li>Interfaces can only have method signatures</li>
<li>Interfaces can't have properties declared on them (although PHP allows them to have constants)</li>
<li>Interfaces can only have public methods</li>
</ul>
<p><strong><a title="PHP - Abstract Classes" href="http://php.net/manual/en/language.oop5.abstract.php" rel="noopener"><span style="text-decoration: underline;">Abstract Classes</span></a>&nbsp;are also contracts for behaviour, but they are more than that</strong>. Unlike <em>Interfaces</em>, <em>Abstract Classes</em> can also, like any other <em>Class,</em> have concrete methods and members/attributes (state) defined on them.&nbsp;</p>
<ul>
<li>Abstract Classes can't be instantiated</li>
<li>Abstract Classes must have at least one abstract method</li>
<li>Abstract Classes can have concrete methods&nbsp;</li>
<li>Abstract Classes can have members/attributes (properties)&nbsp;</li>
<li>Abstract Classes can have all visibility levels (public, protected and private)</li>
</ul>
<blockquote>
<p>Program to an interface, not an implementation.</p>
</blockquote>
<p>What does this mean? In plain words, this means: <a title="Type Hint" href="http://php.net/manual/en/language.oop5.typehinting.php" target="_blank" rel="noopener">Type Hint</a> your variables/properties to <em>Abstractions</em><em> (Interfaces/Abstract Classes)</em>&nbsp;not concrete<em> Classes.</em>&nbsp;</p>
<p>By programming to interfaces, you are decoupling your code's design from its implementation. This enables you to replace pieces of your code more easily down the road if a need arises. Yep, your code's maintainability just skyrocketed. This will also make your code more testable because you will be able to mock certain parts of your system just by implementing the interfaces and replacing the "production" behaviour with the "testing" one.</p>
<p><em>Abstractions</em> shift our focus upwards, from the methods' underlying implementations to their signatures, because in a sense they don't concern us, as long as&nbsp;<em>Abstractions</em>' method signatures and their definitions (arguments and return values) are being respected everything will work. This allows us for a more robust and flexible codebase.&nbsp;Let's take a look at the following examples.</p>
<p><strong>Good example</strong> - Since we programmed to an interface and&nbsp;not an implementation, changing the storage method is just a matter of changing the class we provide through the&nbsp;<em>App's</em> constructor, we are changing just one line of code.&nbsp;</p>
```php
// Storable Interface
interface Storable {
    public function store(array $data): bool;
}

// Database Storage
class Mysql implements Storable {

    protected $conn;

    public function __construct(PDO $conn)
    {
        $this->conn = $conn;
    }

    protected function insert(string $table, array $data): bool
    {
         $columns = implode(',', array_keys($data));

         $placeholders = "?".str_repeat(",?", count($columns) - 1);

         $values = array_values($data);

         $sql = "INSERT INTO $table($columns) VALUES($placeholders)";

         $stmt = $this->pdo->prepare($sql);

         return $stmt->execute($values);
    }

    public function store(array $data): bool
    {
        return $this->insert('emails', $data);
    }

}

// File Storage
class File implements Storable {
   
    protected function write(string $file, array $data): bool
    {
        $file = new \SplFileObject($file.'.txt', 'a+');

        if (!file_exists($file.'.txt')) {
        
            $columns = implode(', ', array_keys($data)); 

            $file->fwrite($values, strlen($values));  

        } else {

            $file = new \SplFileObject($file, 'a+');
        }

        $values = implode(', ', array_values($data)); 

        return (bool) $file->fwrite($values, strlen($values));
    }

    public function store(array $data): bool
    {
        return $this->write('emails', $data);
    }
}

// Client
class App {

    public function __construct(Storable $storable)
    {
         $data = [
             'from' => 'foo@mail.com',
             'to' => 'bar@mail.com',
             'subject' => 'Hello',
             'body' => 'World'
         ];
         $storable->store($data);
    }
}

// Databse App
$dbApp = new App(new Mysql(new Pdo(...$config)));

// File Storage App
$fileApp = new App(new File());
```
<p><strong>Bad example&nbsp;</strong>- Imagine we wanted to change the storage method in this example, now this would amount to more effort than the previous one.</p>
```php
// Database Storage
class Mysql implements Storable {

    protected $conn;

    public function __construct(PDO $conn)
    {
        $this->conn = $conn;
    }

    public function insert(string $table, array $data): bool
    {
         $columns = implode(',', array_keys($data));

         $placeholders = "?".str_repeat(",?", count($columns) - 1);

         $values = array_values($data);

         $sql = "INSERT INTO $table($columns) VALUES($placeholders)";

         $stmt = $this->pdo->prepare($sql);

         return $stmt->execute($values);
    }
}

// File Storage
class File implements Storable {
   
    public function write(string $file, array $data): bool
    {
        $file = new \SplFileObject($file.'.txt', 'a+');

        if (!file_exists($file.'.txt')) {
        
            $columns = implode(', ', array_keys($data)); 

            $file->fwrite($values, strlen($values));  

        } else {

            $file = new \SplFileObject($file, 'a+');
        }

        $values = implode(', ', array_values($data)); 

        return (bool) $file->fwrite($values, strlen($values));
    }
}

// Client
class App {

    public function __construct(Mysql $mysql)
    {
         $data = [
             'from' => 'foo@mail.com',
             'to' => 'bar@mail.com',
             'subject' => 'Hello',
             'body' => 'World'
         ];
         $mysql->insert('emails', $data);
    }
}
```
<p>Of course, both of these are trivial examples but imagine if these classes had many more methods that are being called deeper down in the code, it could give you quite a headache.</p>
<h3><strong>Encapsulation</strong></h3>
<p>Encapsulation and&nbsp;<em>Tell don't ask principle</em> go hand in hand. As we already said, objects should manipulate their own state. Allowing other objects to directly change the state of our object should be avoided. Once more:</p>
<blockquote>
<p>Don't ask for the information you need to do the work; ask for the object that has information to do the work for you. (Allen Hollub - Hollub on Patterns)</p>
</blockquote>
<p>By preserving encapsulation we are writing less bug-prone and more debuggable code because we are being explicit and we only change the objects' state when we send him a message.</p>
<p>We also use encapsulation to hide the complexities and intricacies of our&nbsp;<em>abstractions</em> and their implementations, this way we just keep the "simple stuff" available to the outside world, all those gory details are left hidden.</p>
<p><a title="Visibility" href="http://php.net/manual/en/language.oop5.visibility.php" target="_blank" rel="noopener"><em>Visibility/Accessors</em></a> are the way we ensure our objects stay encapsulated. There are three levels of visibility in PHP as in many other languages:</p>
<ul>
<li><strong>public</strong> - methods and properties are accessible from the outside world. When it comes to&nbsp;<em>public methods</em> they are what make up the public API of our class, those are the methods we want other developers and/or objects to interact with.</li>
<li><strong>protected</strong> - methods and properties are accessible only from within the class and its <em>children</em> (other classes that extend it)</li>
<li><strong>private</strong> - methods and properties are accessible only from within the class in which they are defined</li>
</ul>
<p><em>Getters/Setters&nbsp;</em>also known as&nbsp;<em>accessors&nbsp;</em>and&nbsp;<em>mutators</em> give us the ability to keep our objects encapsulated while at the same time having the ability to access and mutate their state, just instead of accessing it directly we do it through getter/setter methods.&nbsp;</p>
```php
// Without getters/setters
class Article {
   public $slug = 'foo';
}

$article = new Article();

// Imagine we wanted to check for equality
// but forgot to add the second '='.
// See, a simple typo could introduce a bug.
if ($article->slug = 'bar') {
    // Do something awesome here
}


// With getters/setters
class Article {
   proteceted $slug = 'foo';

   public function getSlug(): string 
   {
      return $this->slug;
   }

   public function setSlug(string $slug)
   {
      $this->slug = $slug;
   }
}

$article = new Article();

if ($article->getSlug() == 'bar') {
    // Do something awesome here
}
```
<h3><strong>Inheritance</strong></h3>
<p><a title="Inheritance" href="http://php.net/manual/en/language.oop5.inheritance.php" target="_blank" rel="noopener">Inheritance</a> is self-explanatory, an object will inherit all of the <em>super</em> (parent) classes' methods and attributes unless the visibility of the method is&nbsp;<em>private</em>&nbsp;and we achieve that by extending a class. You might have come across the phrase <em>"Favour Composition over Inheritance"&nbsp;</em>or&nbsp;some go even further and say that <a title="Inheritance is evil" href="https://codeburst.io/inheritance-is-evil-stop-using-it-6c4f1caf5117" target="_blank" rel="noopener">inheritance is evil</a>. In my humble opinion&nbsp;<span style="text-decoration: underline;">inheritance is not bad, bad inheritance is though</span>. Now how do we distinguish between good and bad inheritance?</p>
<div style="display: flex; flex-flow: row; justify-content: center;">
<div>
<blockquote class="twitter-tweet" data-lang="en">
<p dir="ltr" lang="en">Good inheritance is "is a (special case of)". The keyword extends also supports "taxonomy" which objects do better than classes, and "code re-use", which composition is far better for!</p>
&mdash; Pim Elshoff (@Pelshoff) <a href="https://twitter.com/Pelshoff/status/1066973076037005312?ref_src=twsrc%5Etfw">November 26, 2018</a></blockquote>
</div>
</div>
<p>As <a title="Inheritance is a special case of" href="https://twitter.com/Pelshoff/status/1066973076037005312" target="_blank" rel="noopener">@Pelshof</a> perfectly said in his tweet you should look at inheritance as <em>a special case of</em>. We should look at a child class as a <span style="text-decoration: underline;">special case of</span> its&nbsp;<em>superclass</em>, it has all the behaviour of its parent and then some. <span style="text-decoration: underline;">Good inheritance is shallow</span>, you shouldn't go deeper then one level if you really must not and you should inherit from&nbsp;<em>Abstract</em> classes except in those cases where extending a concrete class makes sense, e.g. a concrete BaseController of a framework where you want to abstract a bit from the framework or add some common behaviour.</p>
<p>When you are extending classes you should always have the&nbsp;<em>Single Responsibility Principle</em> on your mind, use it as a litmus test, if you're breaking it by extending it's time for&nbsp;<em>Composition.</em></p>
<p><strong>Composition</strong> <span style="text-decoration: underline;">in simplest terms is breaking down a complex task into multiple reusable classes</span>, instead of inheriting multiple levels deep. Composition vs Inheritance is in a sense like <em>horizontal</em> vs <em>vertical</em> scaling. With composition, you are breaking down your task horizontally, whereas with inheritance you are doing it vertically.</p>
<p style="text-align: center;"><img src="https://sasablagojevic.com/img/content/132/inheritance_composition.png" width="640" height="409" /></p>
<p style="text-align: left;">This illustration makes it more clear, on the left-hand side we have a <em>parent</em> File Class and its <em>child</em> and <em>grandchild</em> Reader and Writer classes respectively. So we broke our example <em>file interaction</em> task vertically.</p>
<p style="text-align: left;">On the right-hand side, we have the File Class and its dependencies*, two independent reusable classes Writer and Reader which we will inject to the File Class through its constructor. In this case, we expanded the responsibilities of the File Class horizontally.&nbsp;</p>
<h3><strong>Polymorphism</strong></h3>
<p>Polymorphism in plain English means that <strong>objects which implement the same interface can do different things</strong> "under the hood", as long as they adhere to the interfaces' definitions, thus the <a title="What does polymorph mean?" href="http://lmgtfy.com/?q=polymorph" target="_blank" rel="noopener"><em>polymorph</em></a>&nbsp;part.</p>
<p>We already covered this a bit when we talked about the&nbsp;<em>Abstraction principle</em>, the complexities and intricacies of the method implementations are hidden underneath the <em>Interface</em> - our one "single" point of entry and exit. We can implement a method in an infinite number of ways as long as we take the defined number of arguments and return what is expected, we're all set.&nbsp; &nbsp;&nbsp;</p>
<p>If you jump back to the&nbsp;<em>Good example</em> in the&nbsp;<em>Abstraction</em> section you will clearly see that it is also polymorphism at play. We have a<em> Storable</em>&nbsp;<em>Interface</em> and two classes which implement it and do two different things.&nbsp;<em>Mysql</em>&nbsp;stores to a database and the <em>File</em> writes to a CSV file.</p>
<h2>Rome</h2>
<p>I was speaking mainly from the perspective of a PHP developer, but all of these concepts can be applied to any programming language that supports the Object-Oriented paradigm. To prove my point let's compare how we&nbsp;would apply the&nbsp;<strong>Abstraction</strong>&nbsp;principle in PHP and Swift for a second.</p>
<p>In PHP we have <em>Interfaces</em>&nbsp;and in Swift we have <em>Protocols</em>, they are the same thing just a different keyword, no issue here,&nbsp;but when it comes to Abstract Classes Swift does not support them.</p>
<p>Although Swift has no notion of Abstract Classes they have a different language construct that allows us to have the same behaviour, namely&nbsp;<em>Protocol Extensions.</em></p>
<p><span style="text-decoration: underline;">Protocol Extensions</span> allow us to extend the protocol and add additional methods and/or properties to it so we can achieve the same behaviour as Abstract Classes in the following way:</p>
```swift
protocol Animal() {
    func sound();
}

extension Animal {
   func numberOfLegs() -> Int {
       return 4;
   }
}

class Cat: Animal {
   func sound() {
       print("woof");
   }
}


class Dog: Animal {
   func sound() {
       print("woof");
   }
}

let dog = Dog();

dog.sound(); // woof

dog.numberOfLegs(); // 4
```
<p>See, these concepts are "languageless" ;)</p>
<p>We should all strive to adhere to these principles, but what these 2.5+ years of working professionally as a developer have taught me is that we should never be too dogmatic and that every rule has an exception.&nbsp;</p>
<hr />
<p>*&nbsp;<em><a title="What are dependencies?" href="https://askubuntu.com/questions/361741/what-are-dependencies" target="_blank" rel="noopener"><strong>Dependency</strong></a>&nbsp;is a broad software engineering term used to refer when a piece of software relies on another one. Coupling (computer&nbsp;programming) In software engineering, coupling or&nbsp;dependency&nbsp;is the degree to which each&nbsp;program&nbsp;module relies on each one of the other modules.&nbsp;Program&nbsp;X uses Library Y.&nbsp;</em></p>