Page 10 of 10

Re: Namespaces and abstract class names

Posted: Wed Feb 16, 2011 11:04 am
by Jonah Bron
These arguments for 100% composition are good, but I guess what we want is a clear-cut answer to the question: "Why should we use composition in a case where inheritance works great?". Pardon me if it's already been answered...

Re: Namespaces and abstract class names

Posted: Wed Feb 16, 2011 6:46 pm
by Jenk
It's late and I am postingvia my phone, so I'll answer briefly and try and come back to this tomorrow :)

I may nit understand the question properly (I am very tired) but my initial answer to that is that it is a case-by-case thing, I don't think I could answer a simple rule for all.

I can imagine employing the Tell; Don't Ask principle would be a big player here. In the context of behaviour should be kept as close to the data/state it is related to as possible; ergo there should be no need to share state across scope.

I'll come back tomorrow to try and elaborate, in the meantime perhaps someone could post an example that I could use/refactor as a demonstration?

Jonah Bron: This is not something that can be simplified to a single hard and fast rule; if it were, it would have been done long ago and this thread would never have derailed so much :p

Re: Namespaces and abstract class names

Posted: Wed Feb 16, 2011 8:46 pm
by Jonah Bron
I just have one question: how does composition handle adding functionality that was not anticipated during during development? Say, for example you want to create a new robot that could jumpUpAndDown() function to the robot. With inheritance, all it takes is creating the new class, and adding the method.

Code: Select all

class JumpingRobot extends Robot {
    function jumpUpAndDown() {
        // ...
    }
}
How could that be done with composition?

Re: Namespaces and abstract class names

Posted: Thu Feb 17, 2011 8:07 am
by alex.barylski
Jonah Bron: This is not something that can be simplified to a single hard and fast rule; if it were, it would have been done long ago and this thread would never have derailed so much :p
Stole the words right out of my mouth. :)
Jonah Bron wrote:I just have one question: how does composition handle adding functionality that was not anticipated during during development? Say, for example you want to create a new robot that could jumpUpAndDown() function to the robot. With inheritance, all it takes is creating the new class, and adding the method.

Code: Select all

class JumpingRobot extends Robot {
    function jumpUpAndDown() {
        // ...
    }
}
How could that be done with composition?
Well, what difference does it make? Typically, if you inject an object, the container (for lack of a better word) would either directly or indirectly delegate method calls to the required composite object. If it's hardcoded, you are working more as everytime you add a method to the container interface you need to manually delegate to the composite. Thankfully PHP has excellent support for dynamic method invocation and this can likely be implemented as a mixin.

Basically all you should have to do is inject your new object into the container and invoke the method on that container. The container does the rest.

Now to answer your question: Using inheritence, you are saying you simply create a new class called Robot2 and add a method called Jump(). You still need to invoke that new mmethod so manual changes to your code are required, regardless, in fact the same work had you used a mixin.

1. Create class Robot2
2. Add method Jump()
3. Invoke $robot->Jump()

Regardless of whether you use inheritence or not this newly added method needs to be invoked, unless you implement a hooking framework that invokes methods based on convention, in which case a composition approach is far more flexible.

HTH

Cheers,
Alex