OOP (course 4): Static methods, Namespaces, Exceptions & Traits! Woh!

Hey Boran Alsaleh!

Excellent question! First, you are 100% correct that both result in an "object inside an object". I would say that "decoration" is a special, philosophical "case" or "subset" of dependency injection.

Let me... try to explain in a bit more of a clear way :). Let's look at 2 different situations:

1) Suppose you are creating an InvoiceGenerator class. Your project already has a DatabaseConnection class that helps you make queries to the database. It doesn't really matter, but let's pretend that this DatabaseConnection class comes from some third-party library that we're using in our project (so, we don't have access to modify this class). Anyways, because our InvoiceGenerator needs to make some database queries, we use dependency injection to "inject" the DatabaseConnection object into InvoiceGenerator. And... that's it! This is aa very normal dependency injection situation.

2) Now suppose that you are having some trouble with "slow queries" in your system. And so, you decide that you want to "calculate" how long *every* query that DatabaseConnection makes and, if it's longer than 100 milliseconds, you will log a message. If DatabaseConnection were a class that you owned, then you could just open that class and add some extra code to determine the "duration" of each query it makes and then log a message if any take longer than 100 milliseconds. BUT... this class comes from a third-party library... and so we do *not* have access to modify the class directly. We *could* put our "duration & logging" code into InvoiceGenerator... but we really want *all* queries across the entire project to have this logic, not just the queries made by InvoiceGenerator.

So, what we effectively want to do is "replace" the DatabaseConnection class in our project with a *completely* different class... and to pass *that* class to any other classes in our project (like InvoiceGenerator) that needs it. Of course... we don't *really* want to replace it - we just want to "run some code" and then allow the normal DatabaseConnection class to do its normal work. To do this, we decide to use "decoration": we create a new LoggingDatabaseConnection, make it implement the same interface as DatabaseConnection (e.g. maybe it has a DatabaseConnectionInterface) and then "inject" the core DatabaseConnection into our LoggingDatatabaseConnection (then we would also update our project to inject our new LoggingDatabaseConnection service into anything that needs it - like InvoiceGenerator). This 100% IS dependency injection. But the *intention* of the LoggingDatabaseConnection is different than some other class that needs the database connection, like InvoiceGenerator:

* A) InvoiceGenerator: injects the database connection so that it can *use* this tool
* B) LoggingDatabaseConnection: injects the database connection so that it can "add" behavior (run code before/after) to the database connection class. And then, because this is our intention, we would then update our project so that anything that needs the database connection (like the InvoiceGenerator) will now receive our LoggingDatabaseConnection object instead of the normal DatabaseConnection object.

So... that's a long way of saying that both are dependency injection. Decoration is one very specific use-case of dependency injection where your intention is to *replace* the object that you have injected.

Let me know if that helps! This stuff is tricky :).

Cheers!

Thank you, Euclides!

Hey, Sander!

Haha, it's awesome! We'll notify you by email if you hit the "Notify me" button at the top right of this page.

Cheers!

Cheers Christophe! Thanks for dropping us this really nice comment - it means a lot :)

I agree with you, specialy abstract class :D

Hey there!

This will be out in late June - so 3-4 weeks from now :). If you hit the "Notify me" button at the top right of this page, we'll send you a one-time email when it comes out.

Cheers!