OOP (course 4): Static methods, Namespaces, Exceptions & Traits! Woh!
Unlock new coding efficiency with this tutorial on Autoloading, Traits, and other crucial OOP elements.
About this course
Finally, we can really unload and see all the cool OOP stuff that we haven't covered yet. These are the last missing pieces that are standing between you and understanding any OO code you meet.
- Static methods
- Class constants
- Namespaces
- Autoloading (RIP
require
statements) __toString
& the other magic functions- Treat that
$object[1]
like an array (ArrayAccess
) - Throwing and catching
a baseballExceptions - Traits! Horizontal code re-use
- Composition Versus Inheritance: Dressing your classes for success
Finally, you're going to start to see some serious pay-off from these new, crazy OO skills you've got. In this tutorial, OO is here to impress us. Dig in.
Next courses in the OOP: Beginner section of the OOP Track!
13 Comments
Thanks for this series of tutorials. That was interesting and awesome !:)
Hello I have a question, I am little bit confused about composition and dependency Injection, what is the Difference between them , in both cases we have defined an obj inside obj?
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!
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!
These four courses are so magical :D I understand some concept that i've never seen before because i'm learning as (as many person i think) self-educated so, thank's a lot and keep going to do some good stuff like that :p (And i think i'm improving my english :p)
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!
A good stuff .Thanks