Namespaces and abstract class names
Moderator: General Moderators
Re: Namespaces and abstract class names
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.
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
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
Well, I'm a little disappointed at that. Namespaces in the context of autoloading are still considered part of the class name ...Jonah Bron wrote:Hm. And it's child class would still use underscores to separate packages?VladSun wrote:I think the namespace must be single-word - the name of the frameworkJust 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".
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.
There are 10 types of people in this world, those who understand binary and those who don't
Re: Namespaces and abstract class names
For me, the "inheritance vs. composition" is like "Skeleton pattern vs. Strategy pattern".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.
There are 10 types of people in this world, those who understand binary and those who don't
- Jonah Bron
- DevNet Master
- Posts: 2764
- Joined: Thu Mar 15, 2007 6:28 pm
- Location: Redding, California
Re: Namespaces and abstract class names
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.John Cartwright wrote:Composition is when one object directly instantiates a new object for it's own purposes (directly coupled).
In what way? Could you give an example?Jenk wrote:Inheritance is more brittle than composition.
Ah, okay. That's good.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.
I'll have to look up the Skeleton pattern to understand that.VladSun wrote:For me, the "inheritance vs. composition" is like "Skeleton pattern vs. Strategy pattern".
Edit: looked up, still don't understand
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
Re: Namespaces and abstract class names
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.
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.
(#10850)
Re: Namespaces and abstract class names
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:
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.
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
Re: Namespaces and abstract class names
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)Jonah Bron wrote: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.John Cartwright wrote:Composition is when one object directly instantiates a new object for it's own purposes (directly coupled).
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.In what way? Could you give an example?Jenk wrote:Inheritance is more brittle than composition.
Re-use is the same, the only part that changes is the part infront of the "->" ($someOtherObject->foo() instead of $this->foo())
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.I'll have to look up the Skeleton pattern to understand that.VladSun wrote:For me, the "inheritance vs. composition" is like "Skeleton pattern vs. Strategy pattern".
Edit: looked up, still don't understand
Re: Namespaces and abstract class names
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:I think he made it up. I've never heard it. I call it inheritance vs composition, not skeleton pattern vs something else.
I've never said "strategy pattern" === "composition" and visa versa.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.
There are 10 types of people in this world, those who understand binary and those who don't
- Jonah Bron
- DevNet Master
- Posts: 2764
- Joined: Thu Mar 15, 2007 6:28 pm
- Location: Redding, California
Re: Namespaces and abstract class names
Christopher and I talked about it some more, and just dropping the suffix is what we came up with.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:
[text]Foo\Bar[/text]
So you're saying it's good because it allows an object to "inherit" multiple objects?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.
Re: Namespaces and abstract class names
Sounds like composition is the solution of http://en.wikipedia.org/wiki/Diamond_problemJonah Bron wrote:So you're saying it's good because it allows an object to "inherit" multiple objects?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.
There are 10 types of people in this world, those who understand binary and those who don't
- John Cartwright
- Site Admin
- Posts: 11470
- Joined: Tue Dec 23, 2003 2:10 am
- Location: Toronto
- Contact:
Re: Namespaces and abstract class names
Yes ... PHP's object model just doesn't have a good way to implement it without composition. Are you suggesting, fundamentally, it's not?Jonah Bron wrote:So you're saying it's good because it allows an object to "inherit" multiple objects?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.
- Jonah Bron
- DevNet Master
- Posts: 2764
- Joined: Thu Mar 15, 2007 6:28 pm
- Location: Redding, California
Re: Namespaces and abstract class names
That clears it up. What's not? I wasn't suggesting anything, just making sure I understood.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?
- John Cartwright
- Site Admin
- Posts: 11470
- Joined: Tue Dec 23, 2003 2:10 am
- Location: Toronto
- Contact:
Re: Namespaces and abstract class names
Gotcha.Jonah Bron wrote:That clears it up. What's not? I wasn't suggesting anything, just making sure I understood.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?
I meant to say: Are you suggesting, fundamentally, multiple inheritance is not a good thing?"What's not?"?
- Jonah Bron
- DevNet Master
- Posts: 2764
- Joined: Thu Mar 15, 2007 6:28 pm
- Location: Redding, California
Re: Namespaces and abstract class names
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.