Namespaces and abstract class names

Not for 'how-to' coding questions but PHP theory instead, this forum is here for those of us who wish to learn about design aspects of programming with PHP.

Moderator: General Moderators

User avatar
Jenk
DevNet Master
Posts: 3587
Joined: Mon Sep 19, 2005 6:24 am
Location: London

Re: Namespaces and abstract class names

Post by Jenk »

Eran wrote:
this is wrong
That's like, your opinion, man ;)

Seriously though, you can't say that is "wrong" - it is just different from the way you do it. You'll need to be more elaborate on why you think each simple operation needs its own class as opposed to being a method on a class that binds those operations together.
Ok, but it's also the opinion of the GoF, Martin Fowler, Michael Feathers, Bob Martin, Jason Gorman, Kent Beck, Nat Price, Steve Freeman.. etc. Every "good code" book out there will tell you this. I'm not going to ignore all those collective years of development experience, just because I think it is "not bad" :)

For one object to have more than one responsibility is possibly the most basic of code smells :)
User avatar
VladSun
DevNet Master
Posts: 4313
Joined: Wed Jun 27, 2007 9:44 am
Location: Sofia, Bulgaria

Re: Namespaces and abstract class names

Post by VladSun »

Jenk wrote:...Ok, but it's also the opinion of the GoF...
Cmooon, Jenk...
That leads us to our second principle of object-oriented design:
Favor object composition over class inheritance.
If my English is good enough, that DOES NOT MEAN : "Do not use inheriatnce EVER".
And that's the one I (and Christopher, IMHO) do argue about.
Last edited by VladSun on Fri Feb 11, 2011 5:56 am, edited 2 times in total.
There are 10 types of people in this world, those who understand binary and those who don't
User avatar
VladSun
DevNet Master
Posts: 4313
Joined: Wed Jun 27, 2007 9:44 am
Location: Sofia, Bulgaria

Re: Namespaces and abstract class names

Post by VladSun »

josh wrote:Or the config object could be passed an instance to the "main object", and would subsequently call a bunch of setter commands on the "main object" to set it up.
Setters and getters are not required to be public ... I use setters and getters in one main context - Events.
Otherwise having a protected/private property and a public /stter/gttr just doenst make sense.

So, I think my exampe is till a valid example of the Inheritance-fans-code-snippets-though-they-do-not-ignore-composition.
There are 10 types of people in this world, those who understand binary and those who don't
User avatar
Eran
DevNet Master
Posts: 3549
Joined: Fri Jan 18, 2008 12:36 am
Location: Israel, ME

Re: Namespaces and abstract class names

Post by Eran »

VladSun wrote: Cmooon, Jenk...
+1

Name dropping won't do this discussion justice. I too favor composition when it adds value, not just for the sake of "doing the right thing". There are many patterns in the GOF book that use inheritance, as far as I recall
User avatar
Jenk
DevNet Master
Posts: 3587
Joined: Mon Sep 19, 2005 6:24 am
Location: London

Re: Namespaces and abstract class names

Post by Jenk »

*bangs head on desk*

One object/class should not hold more than one responsibility or role. I simply defy you to argue that.
User avatar
Jenk
DevNet Master
Posts: 3587
Joined: Mon Sep 19, 2005 6:24 am
Location: London

Re: Namespaces and abstract class names

Post by Jenk »

VladSun wrote:
josh wrote:Or the config object could be passed an instance to the "main object", and would subsequently call a bunch of setter commands on the "main object" to set it up.
Setters and getters are not required to be public ... I use setters and getters in one main context - Events.
Otherwise having a protected/private property and a public /stter/gttr just doenst make sense.

So, I think my exampe is till a valid example of the Inheritance-fans-code-snippets-though-they-do-not-ignore-composition.
If those settings are required at instantiation, they should be on the constructor. If they are settable after this time, setters should be public.

You are using an array as a psuedo object, so why not just use an object?

You are accessing non-public setters from outside the class. Why not make them public?
User avatar
VladSun
DevNet Master
Posts: 4313
Joined: Wed Jun 27, 2007 9:44 am
Location: Sofia, Bulgaria

Re: Namespaces and abstract class names

Post by VladSun »

Jenk wrote:*bangs head on desk*

One object/class should not hold more than one responsibility or role. I simply defy you to argue that.
Who said that?
There are 10 types of people in this world, those who understand binary and those who don't
User avatar
VladSun
DevNet Master
Posts: 4313
Joined: Wed Jun 27, 2007 9:44 am
Location: Sofia, Bulgaria

Re: Namespaces and abstract class names

Post by VladSun »

.
Last edited by VladSun on Fri Feb 11, 2011 6:32 am, edited 1 time in total.
There are 10 types of people in this world, those who understand binary and those who don't
User avatar
Jenk
DevNet Master
Posts: 3587
Joined: Mon Sep 19, 2005 6:24 am
Location: London

Re: Namespaces and abstract class names

Post by Jenk »

I can't believe this actually needs spelling out for you.

Take a look at the $config array you have posted in your example. You are using it as a hashmap of properties, to access protected properties from outside of the internal scope. This is a pseudo object, which is brittle.

Using a settings or config object, with strongly typed properties is much less brittle. Even less brittle is to just use setters.

I'm tiring rapidly of the hair splitting, either calm down and make meaningful posts, without huge bold letters emphasising your desire to shout, or this thread will degenerate further still and stagnate - ruining what could be a good discussion.
User avatar
Christopher
Site Administrator
Posts: 13596
Joined: Wed Aug 25, 2004 7:54 pm
Location: New York, NY, US

Re: Namespaces and abstract class names

Post by Christopher »

Jenk wrote:Ok, but it's also the opinion of the GoF, Martin Fowler, Michael Feathers, Bob Martin, Jason Gorman, Kent Beck, Nat Price, Steve Freeman.. etc. Every "good code" book out there will tell you this. I'm not going to ignore all those collective years of development experience, just because I think it is "not bad" :)

For one object to have more than one responsibility is possibly the most basic of code smells :)
This is an interesting point, although not all those guys and every book will say exactly what you are saying. Maybe the Responsibility Driven Development guy Bob Martin would say something close to what you are saying. I recall that his point was that a class should only have one reason to be changed. I kind of get his idea but I do get the sense that the definition of what a "responsibility" and a "change" are is a little subjective. Still I do think your point gets to the general goal of high cohesion and low coupling.
Jenk wrote:Already in the post asking What to do with different DBs you've listed a number of roles that, in your example, should be maintained by a single object - this is wrong. Each of those roles should be maintained by separate objects, and kept in a composite.
You switched from responsibilities to roles somewhere in there. Those are different concepts. I think an object might have a single responsibility but have several roles -- especially if its functionality is basic/generic. I think we should stick with responsibilities.

And again this gets back to the question of whether a class can use inheritance and have a single responsibility and reason to be changed?
(#10850)
User avatar
VladSun
DevNet Master
Posts: 4313
Joined: Wed Jun 27, 2007 9:44 am
Location: Sofia, Bulgaria

Re: Namespaces and abstract class names

Post by VladSun »

Jenk wrote:I'm tiring rapidly of the hair splitting, either calm down and make meaningful posts, without huge bold letters emphasising your desire to shout, or this thread will degenerate further still and stagnate - ruining what could be a good discussion.
Sorry about these posts here. Sorry Jenk :oops:

I promise I will never post again after 1:00am and drunk :)
In fact I do think I should not post anything in the next 2-3 weeks - quitting smoking makes me nervous :)

See you soon :)
Bye.
There are 10 types of people in this world, those who understand binary and those who don't
josh
DevNet Master
Posts: 4872
Joined: Wed Feb 11, 2004 3:23 pm
Location: Palm beach, Florida

Re: Namespaces and abstract class names

Post by josh »

Christopher wrote: I kind of get his idea but I do get the sense that the definition of what a "responsibility" and a "change" are is a little subjective.
Sure, but what's not suggestive is that "1 reason to change" and "1 responsibility" mean roughly the same thing.

@Jonah
As for splitting up the classes being "overkill", and resulting in too many classes, I addressed that. There will be more classes. There will be more overall methods.

Abstraction - ten methods 100 lines long.
Composition - ten classes, ten methods per class 10 lines long.

To me composition promotes superior organization, having a few classes isn't a criticism of composition to me. Whereas like Jenk points out, mixing responsibilities is pretty much self evidently "wrong".

@Vlad
Yeah, you wouldn't need to duplicate the query logic, it would just live on a query object that each adapter holds an instance to. They could even use the query() method via __call so that the fact its delegating would be transparent to the programmer (although I don't recommend relying on __call, better to just make the fact composition is happening obvious)


@Eran
As for GoF using inheritance.. which patterns? The only ones I can think of were patterns for dealing with problems that inheritance created in the first place.
Last edited by josh on Fri Feb 11, 2011 10:29 am, edited 1 time in total.
User avatar
John Cartwright
Site Admin
Posts: 11470
Joined: Tue Dec 23, 2003 2:10 am
Location: Toronto
Contact:

Re: Namespaces and abstract class names

Post by John Cartwright »

It's funny that I always considered adapter scenarios to be best accomplished with abstraction.

Today the specs changed on a project involving writing an ACL library and after some major refactoring, composition was the far superior solution.

Not that I'm adding anything to this discussion, I just thought I'd mention this thread rubbed off on me a little :D
josh
DevNet Master
Posts: 4872
Joined: Wed Feb 11, 2004 3:23 pm
Location: Palm beach, Florida

Re: Namespaces and abstract class names

Post by josh »

John Cartwright wrote:after some major refactoring, composition was the far superior solution.
Could you elaborate?
User avatar
John Cartwright
Site Admin
Posts: 11470
Joined: Tue Dec 23, 2003 2:10 am
Location: Toronto
Contact:

Re: Namespaces and abstract class names

Post by John Cartwright »

Basically I needed to attach adapters to many different objects down the hierarchy, which either needed to read from either the database or memcache depending whether the information was available in memcache. The ACL object allowed you to override the adapters, specifically for dependency injection, and would bubble the adapters to all the classes listening (these classes implemented an abstract adapter class, and also handled how default adapters should be handled).

By using composition, I now have an adapter object, which is passed down the hierarchy instead, and the child classes can pull their adapters from there.
Post Reply