Resources?

[KevinM1]

Are there any resources the gurus here could recommend for an OOP newbie?  Any books, sites, etc.?  I have one book (PHP Objects, Patterns, and Practice), but it's not edited very well, so it can get confusing at times.  I'd like to know if there are any particular things I should check out before relying on Amazon and hoping I don't blow my $$ on a book that really isn't as good as its rating.

[paul2463]

google

 

the best resource I have found for helping my PHP scripting

 

prefix your search with PHP

[redbullmarky]

have a look at the "resources" sticky at the top of the Application Design forum. The resources I use constantly and have bookmarked are all in there and, like paul said, coupled with Google, you cant go far wrong. Personally with all the freely available stuff (via Google), I can't see me personally buying another book again...

[obsidian]

I have one book (PHP Objects, Patterns, and Practice), but it's not edited very well, so it can get confusing at times.

 

I'll have to argue that it's the mass of material that's covered in that book, not the editing, that can cause confusion. I, too, use the same book, and I've found it to be the best resource by far that I have found and gleaned from in the PHP OOP realm. Take your time with it, and it will come to you. It's definitely one that builds as you go through, too, so you can't just skip examples in it.

[KevinM1]

I have one book (PHP Objects, Patterns, and Practice), but it's not edited very well, so it can get confusing at times.

 

I'll have to argue that it's the mass of material that's covered in that book, not the editing, that can cause confusion. I, too, use the same book, and I've found it to be the best resource by far that I have found and gleaned from in the PHP OOP realm. Take your time with it, and it will come to you. It's definitely one that builds as you go through, too, so you can't just skip examples in it.

 

Heh, I think I'm just dense, then.  I've re-read the first few chapters a few times now, and beyond the syntactical stuff I already knew about (defining classes, initializing objects, using __autoload, etc), a lot of the rest of it makes me scratch my head.  I think some of it is the author -- case in point, the first use of the Strategy pattern comes out of nowhere, and he doesn't really describe it very well in that first use (certainly not as well as the Factory patterns).  Then there's the Factory pattern and Abstract Factory pattern.  To my untrained eye, they look virtually identical.  There are some code examples where it looks like he forgot to mention a database table name, or perhaps used the wrong name (I believe one of them is the ReflectionAPI module loader example, or maybe the Factory example when he was describing exceptions).  I dunno...it just doesn't seem as clear and concise as it could be to me, and things like that, as little as some may be, tend to throw me off.

[448191]

I own this book too, and I agree it's pretty good. I mean, you still have to read the obligatory GoF and PoEAA (of course ) but I think this book does a better job than other php books. Like php|architects guide to design patterns for example. Their interpretation of Strategy is a rape (pardon the explicit terms), that uses 'key-to-class' mapping. If you go scouting for online resources, be sure to skip over Alejandro Gervasio's (DevShed) tutorial on the pattern. His is even worse. Both gutter extensibility. The Strategy pattern is pretty simple, the explanation in Zandstra's book should be adequate. But I agree that it skips over the possible implementation pitfalls.

 

Strategy is meant to eliminate conditionals, not move them into an other class' constructor. In short, the patterns intent is too encapsulate different algorithms in their own subtype. This to decouple the chosen algorithm from the context. The two alternatives (conditionals and inheritance) easily (inevitably) cause code duplication (violation of the DRY principle).

 

Traditional Strategy client code (like in the GoF and Zandstra's book) looks like this:

 

$aSpecializedObject = new Context(new SpecificAlgorithm);

 

In the context's constructor, some action like this is performed:

 

public function __construct(StrategyType $strategyObject){		
$this->strategyObject = $strategyObject;
}

 

Generic methods in the context delegate to their Strategy counterparts:

 

public function doSomething($arg){
return $this->strategyObject->doSomething($arg);
}

 

Alejandro and php|architect do something stupid. In an attempt to simplify the client code, and hide the business of instantiating Strategy objects from it (an admirable goal in itself, e.g. maybe you want to use factories to instantiate the Strategy objects), they map a string to a class, requiring amending of code when you add a new algorithm:

 

public function __construct($strategyString){
switch($strategyString){
	case "someStrategy": 
	$this->strategy = new someStrategyClass();
	break;
	case "someOtherStrategy": 
	$this->strategy = new someOtherStrategy();
	break;
	default:
	throw new Exception('Invalid strategy.');
}
}

 

When something like that can be accomplished in other (simpler) ways that are far more (or rather 'are') extensible. The most simple being depending on a basic naming scheme:

 

public function __construct($strategyString){	
$strategyClass = $strategyString.'Algorithm';
if(!class_exists($strategyClass)){
	throw new StrategyException("Class for algorithm $strategyString does not exist.");
}
$this->strategyObject = new $strategyClass;
}

 

Taking it a tiny step further, the chosen strategy might depend on the subtype of an argument:

 

public function __construct(someSuperType $subject){

        $this->subject = $subject;
$strategyClass = get_class($subject).'Algorithm';
$this->strategyObject = new $strategyClass;
}

 

Zandstra uses this type of mapping too in some of his other examples. So I guess the moral of the story is, yes, this is indeed a good book, you could do a LOT worse. If at some point you feel parts are being skipped over to quickly (and in some cases it probably does, but do you really feel like reading a 1k page book that lays out every possible detail?), read on. Read on? Yes, just move on. Many patterns are closely related, and the order in which they are discussed in the book might not be the best order for you personally to learn them. Feel free to skimp back and forth.

 

 

 

[KevinM1]

Wow, awesome post!  Thanks a lot!