Object Composition FTW!

Wooo! Cheers Jeremy Carlson :)

Hey Aristotele,

Thank you for you feedback! It made our day! :)

Cheers!

Hey Brian!

We are glad to hear that you find useful our tutorials, we make them with passion ;)

Cheers!

Hey @Hristo-I!

Sorry for my very slow reply! To be totally honest, I'm not sure :). Coming from the PHP world, object aggregation isn't a term that I'm even familiar with. This may mean it's less common in PHP... or may just be a product of the fact that php devs have called this "object composition" and that has "caught on" much more than object aggregation. From some quick searching, these concepts are quite similar. The best I can say is this:

• In PHP, we sometimes have this problem where we want to extend the behavior of a given class - often a 3rd party class.
• Instead of trying to sub-class that 3rd party class, we implement the same interface the instruct the system to use OUR object instead of the original 3rd-party object, but to pass that 3rd party object TO our custom class. This allows us to call the original 3rd party object, but also add behavior before and after.

So the key thing is that we're showing a strategy for solving a specific problem. And, in PHP, we tend to call this solution "object composition". To the specifics of composition vs aggregation, I will fully admit that I don't know the difference. However, about this:

So in that case isn't "Composition" called when the storage object is created inside the LoggableShipStorage constructor and "Aggregation" when is past from the outside as the example?

I don't know about the correct naming, but the second part - where it is passed from the outside - is a much more common thing to do. And yes, this might technically be "aggregation" as aggregation implies a weaker relationship (i.e. a relationship controlled from the outside).

I hope this helps... at least to know that the difference is subtle and you are probably thinking about this already more deeply than most devs are :).

Cheers!

Hey Naschkatze,

Composition and dependency injection could be seen as the same thing because you achieve the same goal, which is composing your classes. For example, a big method could be split into two different classes and just inject (adding a property field), let's say, classB into classA, so classA would make a call to some method on classB. Does it make sense to you?

Cheers!

Hey Roi!

Congrats! You did a huge job finishing all the episodes in OOP :) And we're happy to hear it was useful for you! If something was confusing - feel free to leave a comment below the related chapter. Fairly speaking, yeah... there might be some tricky challenges, that's because we just wanted to make things not that easy at the fist sight ;)

Good luck with further learning!

Cheers!

Hey @Ana

Nice question! If you look at ShipLoader::getShips() you will notice that it hardcodes an extra Ship into the array, so the Logger will never know about it. I hope it anwsers to your question :)

Cheers!

Hey Ivan!

Actually, yes! There are many different use-cases for the proxy pattern, but this is certainly one of them: the LoggableShipStorage is effectively a proxy for whatever other ship storage we pass into it. In fact, it fits the "smart reference" proxy pattern that Marco (core Doctrine contributor) talks about in his presentation here: http://ocramius.github.io/p...

Cheers!

Totally :). I think using inheritance is a bit more common when people develop their *own* applications, as it's a bit more straightforward, and you probably don't need the flexibility that composition gives you. This happens a lot actually: if you're building a re-usable library, then you often need to code things "more correct" than you should need to in your own code :).

Cheers!

Laaaame :). Thanks a lot for reporting that - fixed at https://github.com/knpunive... I wanted to give you a GitHub shout-out, but couldn't find your user!

Cheers!

You couldn't as I wasn't registered until now ;)

When I mess up (i.e. by forgetting the return) we keep the code and script correct :). But we'll add a note about the missing return.

Thanks!