Page 2 of 10
Re: Namespaces and abstract class names
Posted: Tue Feb 01, 2011 12:25 pm
by Jenk
As above, it uses an objects external interface, rather than internal. Basically, a composite object is an object with dependency objects, rather than an implementation of a different object.
The reason to abstract a class is to share common behaviour between multiple implementations. This is the same reason to have a composition. I prefer the latter. Inheritance is more brittle than composition.
Re: Namespaces and abstract class names
Posted: Tue Feb 01, 2011 1:03 pm
by josh
Correction! composition does not require object A to instantiate object B, it means object A holds an instance to object B, regardless of who instantiates it! And I agree with Jenk 100%. Also I don't think Foo_Bar is "outside" of the Foo_Bar package, I track packages with a docblock, or file/folder name, or on a whiteboard. As Vlad argues, packages != namespaces, at least they don't have to.
Re: Namespaces and abstract class names
Posted: Tue Feb 01, 2011 1:06 pm
by VladSun
Jonah Bron wrote:
VladSun wrote:I think the namespace must be single-word - the name of the framework

Just like Zend and ZendX exist... IMHO, a namespace should be an unique identifier. I remember Java classes can be put in "com.provider.class....." etc. "namespace".
Hm. And it's child class would still use underscores to separate packages?
Well, I'm a little disappointed at that. Namespaces in the context of autoloading are still considered part of the class name ...
One can't distinguish between namespace name and class prefix (AFAIK) in Zend autoloader. If namespaces were unique (by definition) then it worths using them.
Re: Namespaces and abstract class names
Posted: Tue Feb 01, 2011 1:10 pm
by VladSun
Jenk wrote:My opinion on that is because it is more difficult to enforce behaviour through composition than it is through inheritance.
Composition is difficult to do, I am fully aware. However it is very easy to do inheritance badly, but just as difficult to do cleanly.
Note that there isn't a "composition is easy to do badly" in that statement.
For me, the "inheritance vs. composition" is like "Skeleton pattern vs. Strategy pattern".
Re: Namespaces and abstract class names
Posted: Tue Feb 01, 2011 1:34 pm
by Jonah Bron
John Cartwright wrote:Composition is when one object directly instantiates a new object for it's own purposes (directly coupled).
Ah, so the child class would instantiate the parent? What's the advantage of that? I'm obviously no expert, but inheritance just makes more sense, and seems more organized.
Jenk wrote:Inheritance is more brittle than composition.
In what way? Could you give an example?
josh wrote:Also I don't think Foo_Bar is "outside" of the Foo_Bar package, I track packages with a docblock, or file/folder name, or on a whiteboard.
Ah, okay. That's good.
VladSun wrote:For me, the "inheritance vs. composition" is like "Skeleton pattern vs. Strategy pattern".
I'll have to look up the Skeleton pattern to understand that.
Edit: looked up, still don't understand

Re: Namespaces and abstract class names
Posted: Tue Feb 01, 2011 6:55 pm
by Christopher
Ok ... so if I can summarize...
Josh says give the class a descriptive name, such as just Foo_Bar or something like Foo_Bar_Blueprint.
Vlad says to use a single namespace like My\Foo_Bar so using _Abstract does not matter, but doesn't like that name anyway.
Jenk had no comment on the namespace related naming, but thinks composition is better than inheritance.
Re: Namespaces and abstract class names
Posted: Wed Feb 02, 2011 1:45 am
by Zyxist
You wrote you follow Zend conventions, so I assume you've already familiarized with this document:
http://groups.google.com/group/php-stan ... l-proposal
This basic class naming standard is currently being adapted by Zend Framework 2, Symfony 2, Doctrine 2 and several other projects. Many of them do not use underscores in class names at all. The solutions for dealing with abstract classes and interfaces are pretty simple. The developers either do not mark that the class is abstract at all, or use "AbstractFoo" name:
Code: Select all
\Foo\Bar\AbstractBar
\Foo\Bar\ConcreteBar
\Foo\Joe\JoeInterface
\Foo\Joe\SomeJoeImplementation
VladSun's complaints about the way the namespaces are handled are actually pretty good things, because they allow to handle both the old and the new code in the same autoloader. There have appeared several autoloaders for the standard presented above so far and they have no problem with that.
Re: Namespaces and abstract class names
Posted: Wed Feb 02, 2011 2:07 am
by josh
Jonah Bron wrote:John Cartwright wrote:Composition is when one object directly instantiates a new object for it's own purposes (directly coupled).
Ah, so the child class would instantiate the parent? What's the advantage of that? I'm obviously no expert, but inheritance just makes more sense, and seems more organized.
No, typically the parent instantiates the child, or is passed an instance of the child thru it's constructor. I prefer the latter, passing it into the constructor (dependency Injection)
Jenk wrote:Inheritance is more brittle than composition.
In what way? Could you give an example?
For one, collisions between members of the same name. The biggest difference to me isn't that its brittle, its the orthogonality. With inheritance, if you don't have the ability to use a single base class throughout the whole project, you are going to start needing to copy & paste at some point. And like Jenk said, just because putting a base class is easy doesn't make it good. For one you have multiple responsibilities in that base class, which makes it not good. Whereas there can be a maximum of 1 superclass for a class, my
object can hold references to an unlimited number of objects from an unlimited number of classes. That's the big difference.
Re-use is the same, the only part that changes is the part infront of the "->" ($someOtherObject->foo() instead of $this->foo())
VladSun wrote:For me, the "inheritance vs. composition" is like "Skeleton pattern vs. Strategy pattern".
I'll have to look up the Skeleton pattern to understand that.
Edit: looked up, still don't understand

I think he made it up. I've never heard it. I call it inheritance vs composition, not skeleton pattern vs something else. Strategy pattern isn't the same thing as composition. That's like saying all electronic music is techno. Some of it is, but not all. Strategy pattern is a pattern that uses composition, using the strategy pattern is just one way to employ composition... you could also use for example the composite pattern.
Re: Namespaces and abstract class names
Posted: Wed Feb 02, 2011 5:50 am
by VladSun
josh wrote:I think he made it up. I've never heard it. I call it inheritance vs composition, not skeleton pattern vs something else.
It was the closest comparison I could think of (maybe not the best). What I meant is that inheritance and composition do not exclude each other. And should not be. Each of them is better to be used in different cases. I just complain about ignoring the one in favor of the other.
josh wrote:Strategy pattern isn't the same thing as composition. That's like saying all electronic music is techno. Some of it is, but not all. Strategy pattern is a pattern that uses composition, using the strategy pattern is just one way to employ composition... you could also use for example the composite pattern.
I've never said "strategy pattern" === "composition" and visa versa.
Re: Namespaces and abstract class names
Posted: Wed Feb 02, 2011 11:15 am
by Jonah Bron
Zyxist wrote:This basic class naming standard is currently being adapted by Zend Framework 2, Symfony 2, Doctrine 2 and several other projects. Many of them do not use underscores in class names at all. The solutions for dealing with abstract classes and interfaces are pretty simple. The developers either do not mark that the class is abstract at all, or use "AbstractFoo" name:
Christopher and I talked about it some more, and just dropping the suffix is what we came up with.
[text]Foo\Bar[/text]
josh wrote:For one, collisions between members of the same name. The biggest difference to me isn't that its brittle, its the orthogonality. With inheritance, if you don't have the ability to use a single base class throughout the whole project, you are going to start needing to copy & paste at some point. And like Jenk said, just because putting a base class is easy doesn't make it good. For one you have multiple responsibilities in that base class, which makes it not good. Whereas there can be a maximum of 1 superclass for a class, my object can hold references to an unlimited number of objects from an unlimited number of classes. That's the big difference.
So you're saying it's good because it allows an object to "inherit" multiple objects?
Re: Namespaces and abstract class names
Posted: Wed Feb 02, 2011 11:22 am
by VladSun
Jonah Bron wrote:josh wrote:For one, collisions between members of the same name. The biggest difference to me isn't that its brittle, its the orthogonality. With inheritance, if you don't have the ability to use a single base class throughout the whole project, you are going to start needing to copy & paste at some point. And like Jenk said, just because putting a base class is easy doesn't make it good. For one you have multiple responsibilities in that base class, which makes it not good. Whereas there can be a maximum of 1 superclass for a class, my object can hold references to an unlimited number of objects from an unlimited number of classes. That's the big difference.
So you're saying it's good because it allows an object to "inherit" multiple objects?
Sounds like composition is the solution of
http://en.wikipedia.org/wiki/Diamond_problem 
Re: Namespaces and abstract class names
Posted: Wed Feb 02, 2011 3:02 pm
by John Cartwright
Jonah Bron wrote:
josh wrote:For one, collisions between members of the same name. The biggest difference to me isn't that its brittle, its the orthogonality. With inheritance, if you don't have the ability to use a single base class throughout the whole project, you are going to start needing to copy & paste at some point. And like Jenk said, just because putting a base class is easy doesn't make it good. For one you have multiple responsibilities in that base class, which makes it not good. Whereas there can be a maximum of 1 superclass for a class, my object can hold references to an unlimited number of objects from an unlimited number of classes. That's the big difference.
So you're saying it's good because it allows an object to "inherit" multiple objects?
Yes ... PHP's object model just doesn't have a good way to implement it without composition. Are you suggesting, fundamentally, it's not?
Re: Namespaces and abstract class names
Posted: Wed Feb 02, 2011 3:12 pm
by Jonah Bron
John Cartwright wrote:Yes ... PHP's object model just doesn't have a good way to implement it without composition. Are you suggesting, fundamentally, it's not?
That clears it up. What's not? I wasn't suggesting anything, just making sure I understood.
Re: Namespaces and abstract class names
Posted: Wed Feb 02, 2011 3:17 pm
by John Cartwright
Jonah Bron wrote:John Cartwright wrote:Yes ... PHP's object model just doesn't have a good way to implement it without composition. Are you suggesting, fundamentally, it's not?
That clears it up. What's not? I wasn't suggesting anything, just making sure I understood.
Gotcha.
"What's not?"?
I meant to say: Are you suggesting, fundamentally, multiple inheritance is not a good thing?
Re: Namespaces and abstract class names
Posted: Wed Feb 02, 2011 3:21 pm
by Jonah Bron
I haven't had years of experience to back my assessment, but I'd say that it's good to have only single inheritance, and composition when it's needed.