Slashdot Mirror
PHP 5 Objects, Patterns and Practice
Daniel Holmes writes "In addition to using PHP to 'just get the job done' for years now, I've been running a humble user group here in the
Midwest. As such, I have read numerous books on and around the
subject, always looking for something great to inspire my
colleagues, group members and myself alike. There are a
metric ton of books out there that will walk you through PHP
syntax -- this is not one of them. If you are looking for a book on
rapidly developing prototype sites, or writing lots of
HTML-embedded PHP, just keep looking. But if you have read even
one of those books, or just felt like your programming style itself
could use a little upgrade, then go get yourself a copy of PHP 5
Objects, Patterns, and Practice by Matt Zandstra." Read on for the rest of Holmes's review.
PHP 5 Objects, Patterns and Practice
author
Matt Zandstra
pages
437
publisher
Apress
rating
10
reviewer
Daniel Holmes
ISBN
1590593804
summary
A powerful tour though PHP 5's object-oriented features; leveraging the power of design patterns and developer best-practices.
For around 40 bucks, you will get a book separated into three main parts, as the title suggests; plus an Introduction, Conclusion and Appendix. However, you also get an amazing level of detail, insight, and plenty of lessons from the (even non-PHP) programming greats. In just over 400 pages I saw hints as well as direct references to some of the best texts in the business: The Pragmatic Programmer, "the GoF", "Enterprise Patterns" and a host more that I will touch on later. The point is: if you have seen true object-oriented development, and have had trouble using these concepts in PHP; don't despair any longer. Matt has done all the work for you--all you need is a weekend or two to do a little reading. Part I - Introduction As you would expect, Part I really sets the stage for the whole book. It points out where the typical state of PHP development is, and (frankly) why we all need to read Matt's book. He does this by telling a great story of a project life cycle gone badly. As many of you know, systems are easy as they are small, but as they grow things often get out of control without proper care and feeding. This section is important as so many good PHP developers don't even know why their code has grown so rapidly out of their control. Don't skip it, even if you know better.
Part II - Objects In Chapter 2, we read the story of the evolution of PHP as a language -- specifically in regards to its object-oriented (OO) constructs. This is nice in that the author presents it in a way so as to not insult the procedural crowd -- something I often struggle with around this topic. Matt's writing style is immediately approachable; he does not come off as the pretentious object-oriented zealot you might expect from the lengthy title.
You also learn that his lessons will take you way beyond just the syntax. Knowing the ins and outs of PHP's oo syntax is not enough: "You must first choose the right participants for your system, and decide the best ways for them to interact." Now that's something you rarely get in a PHP book.
In Chapter 3, we begin to review the new syntax introduced in PHP 5; just to make sure we are all on the same page. One nice feature here is that Matt uses "sidebars" to point out everything that isn't available in PHP 4. This makes it easy to pass over if you are starting with PHP 5, but it also makes the information available for the rest of us.
It is important to note that this chapter gradually and effectively introduces the layers of OO syntax available in PHP 5. Each lesson or feature simply builds on the next. This makes it nice because you can stop, try things out, read some more, etc.
Chapter 4 takes us a little deeper into PHP 5's OO syntax. It is quite helpful that Zandstra breaks up Chapter 3 and Chapter 4. If you are new to OO syntax, the end of Chapter 3 makes a great place to stop and reflect for the night. Seriously, go to bed and let it sink in.
As you can imagine, the "Advanced Features" include concepts such as:
These are not particularly easy topics to master the first time you hear them. However, I think Matt finds a great balance of code and presentation to get the ideas across.
His section on Exceptions alone should be required reading for anyone using PHP 5. Again, not only does he show what they do, he really explains how they will actually help you out.
By the time you get to Chapter 5, you are ready to learn a handful of tips and techniques you can use to keep yourself out of trouble. First off, as PHP is lacking support for true namespaces, Matt shows us the PEAR method of using naming conventions to avoid namespace conflicts. We also learn about using include, require and the new (and possibly controversial) __autoload() function. Of course, there are pitfalls with nearly all of this, and Matt makes sure we know them before we leave the chapter.
Finally he walks us through various reflection techniques. Naturally, starting with simple, function-based reflection. Then taking us through a very complete tour of the new class-based, Reflection API. If you haven't used this, it is a very clean way to expose every nook and cranny of your objects and classes at runtime. Something that can save your sanity in a language that lets you change your API on the fly. Again, it's not just a bunch of talk; there are plenty of great examples to get you there.
By the time you get to Chapter 6, it is time to take another break. Better yet, if this is all new to you stop and play with the code for a bit. Sure you could keep reading, but it will really help if you have the syntax and concepts down so you don't keep flipping back.
Again, Zandstra doesn't just jump straight into design examples; rather, he walks you through why you should even care. Sure, many of us have features in mind and run straight for the finish line ... but this can really get painful on older systems. He even takes a moment to point out one of the biggest traps for developers new to OO. "The presence of classes does not guarantee object-oriented design, even in languages like Java, which forces you to do everything in a class."
The chapter hooks you right away with an example done procedurally and another in OO using appropriate abstract methods. The point is clear: with proper design, you can get away from the Giant If-Else Blocks of Doom and pave the way towards actually keeping up with your client's requests.
Finally, he defines and relates the concepts of Responsibility, Coupling, Cohesion and Orthogonality.
Another great nugget of advice has been planted in this chapter. According to Zandstra, the art of selecting and defining objects "...is far more than just finding the 'things'" in a system. "If you see a class as a noun, a subject for any number of verbs, then you may find it bloating as on going development and requirement changes call for it to do more and more things."
Never before have I seen a simple sentence more completely dispel the inappropriate "object oriented" lessons you may have learned in school. If anything; if you find that it hits too close to home, you will pay attention to what he is about to say!
After telling a story about classes gone badly: "How should we think about defining classes? The best approach is to think of a class as having a primary responsibility, and to make that responsibility as singular and focused as possible. Put the responsibility into words." He continues, referring to the writings of Peter Coad: "If your sentence gets too long, or mired in clauses, it is probably time to consider defining new classes along the lines of some of the responsibilities you have described."
Our tour continues through the basics of polymorphisms and encapsulation. After which, Matt provides us with "four signposts" to help identify problems that can creep into our designs:
For more detail on these tell-tale signs that are probably represented somewhere in your code, go buy the book.
Matt really surprised me in this chapter. After getting us up on all the OO syntax and concept basics, he pulls out the UML. What was so surprising is how easy and approachable he made this introduction. In just a few pages, you learn enough to diagram and interpret inheritance, associations, aggregation and composition, and actually know what all that means. As an added bonus, he even gives a useful introduction to sequence diagrams.
Now, a chapter on UML (or some diagramming set) is usually included in any pattern book. But, this is different from those others. Matt provides s a short, easy to understand introduction to just enough UML to communicate your concepts and processes. A very cool bonus indeed.
Part III - Patterns As Matt says in chapter 1, this book stands on the work of giants. He makes this obvious in parts III and IV. While some may say that he is just repeating what others are saying, I would disagree. The value he adds in basing the patterns in examples you can actually picture writing yourself is worth every delicious page.
After walking us though the why-and-how of how "design patterns" came to be, Matt again makes us actually care about spending the time to learn as many as possible and to use them when it is appropriate. Again, he does a great job of breaking these tough concepts into bite-sized chunks. Don't get me wrong, though; you'll be full after reading the chapters in this section.
I won't go into great detail, but I need to at least provide you with an idea of the patterns you will learn about in this section.
In chapter 8, Matt describes some of the most low-cost, high-return concepts around: composition, decoupling, "patternitis" and the golden rule of OO development -- "Code to an interface, not an implementation."
In chapter 9 he introduces us to some "creational" patterns: The singleton, abstract factory, factory method and prototype.
Chapter 10 focuses on "structural" patterns. The ones he focuses on are the composite, decorator and the facade.
You should note, most of this is PHP written as if we were developing a civ-style, Web-delivered game. This is much easier for "the rest of us" to digest and apply these examples than the GoF's examples of building a large-scale word processor. No disrespect to the bible that is the GoF, but if you have read about design patterns, and still need a little help applying the ideas to your day job, parts III and IV were written for you.
Chapter 11 introduces us to some great task and message management patterns: Interpreter, Visitor, Strategy, Command and Observer.
Finally, Chapter 12 drives us home and provides us with a great look at even more great patterns and explains how they fit into the three tiers of sustainable web development: presentation, business logic and data retrieval and storage.
Presentation
Part IV - Practice This is a very important section: like the intro, please don't be tempted to skip it. Matt reminds us while learning code and code design is great, it teaches you nothing about the day-to-day tasks associated with actually keeping the project alive and kicking.
In "Borrowing the Wheel," he shares with us a fantastic piece of advice; one that many PHP developers could stand to listen to:
Please, take another moment to read that again. If this sounds eerily familiar, please stop reading my review and head strait for your nearest book dealer.
In these chapters we naturally get the (hopefully) obvious hints: use version control, write tests, use PEAR, etc. But, where else will you find all this along with excellent references on actually using PHPUnit2, writing your own PEAR Packages for managing even your own code, actual phpdoc syntax and examples ... not just the act of documenting your code, but using the phpdoc command line tool. And with the section on using cvs, you will have absolutely no excuse but to save your life with some form of version control.
Matt even devotes an entire chapter to managing automated builds with Phing, the PHP equivalent of Apache's ant or C's make.
Most of this information is available in countless forums, articles and websites where you could learn about all of these topics for "free." Or, you could read this section in an afternoon or two and begin amazing your friends and better managing your code right away.
Part V - Conclusions Matt's summary and overview is a great recap of the journey he has put us on. But, on top of that, he outlines some of the essentials that he had to leave out. Here he at least mentions the importance of tools such as bugzilla, mail lists and a wiki for all that other documentation.
Looking at the Bibliography (and all the places he gives credit where credit is due) is like looking at the reading list of nearly every great programmer. You will find books such as: Core J2EE Patterns, Design Patterns (GoF), Extreme Programming Explained, A Pattern Language, Patterns of Enterprise Application Architecture, The Pragmatic Programmer, Refactoring and UML distilled. This is, of course, along with many on-line articles and websites.
Sure, you could spend years reading all of these sources (and some you still should) but unless you get paid to read, do yourself a favor and get some of the best of all of these texts, tailored to you in PHP and delivered in just over 400 pages. My General Impressions
As I mentioned earlier, one of my favorite features of this book is that the examples are "real." This is not some collection of abstract examples like building the next great competitor to Word -- these are website concepts we mere mortals can relate to, such as product catalogs, games, invoices, and the like. You know, the stuff we actually do for a living.
This book does not cover loops, conditionals, functions, operators or any of the non-OO basics of PHP, and believe me, I am grateful. If you would like an introduction to the language of PHP, simply check out php.net or one of the many great introductory books.
I would certainly recommend this book (as if there was any doubt) to any PHP developer. This is especially true for anyone interested in learning more about using objects and classes more appropriately than ever before.
I would also recommend this book to any Java, Ruby or Python developer out there who hears the letters PHP in a sentence and immediately responds with any number of colorful phrases. As we have all read the Pragmatic Programmer by now, we know we can learn something from reading up on any language, and PHP has never been better than it is today.
Finally, I would tell any web application developer who is looking for a quick way to absorb and comprehend the meat of some of the best development and design books ever written.
Read it for yourself and I think you will agree: the desk of nearly every PHP application developer will one day be holding a copy of this book.
Daniel Holmes maintains the PHP User Group in Kansas City since its inception in 2000. He is also the Systems Integration Manager at JCCC in Overland Park, KS. You can purchase PHP 5 Objects, Patterns and Practice from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
For around 40 bucks, you will get a book separated into three main parts, as the title suggests; plus an Introduction, Conclusion and Appendix. However, you also get an amazing level of detail, insight, and plenty of lessons from the (even non-PHP) programming greats. In just over 400 pages I saw hints as well as direct references to some of the best texts in the business: The Pragmatic Programmer, "the GoF", "Enterprise Patterns" and a host more that I will touch on later. The point is: if you have seen true object-oriented development, and have had trouble using these concepts in PHP; don't despair any longer. Matt has done all the work for you--all you need is a weekend or two to do a little reading. Part I - Introduction As you would expect, Part I really sets the stage for the whole book. It points out where the typical state of PHP development is, and (frankly) why we all need to read Matt's book. He does this by telling a great story of a project life cycle gone badly. As many of you know, systems are easy as they are small, but as they grow things often get out of control without proper care and feeding. This section is important as so many good PHP developers don't even know why their code has grown so rapidly out of their control. Don't skip it, even if you know better.
Part II - Objects In Chapter 2, we read the story of the evolution of PHP as a language -- specifically in regards to its object-oriented (OO) constructs. This is nice in that the author presents it in a way so as to not insult the procedural crowd -- something I often struggle with around this topic. Matt's writing style is immediately approachable; he does not come off as the pretentious object-oriented zealot you might expect from the lengthy title.
You also learn that his lessons will take you way beyond just the syntax. Knowing the ins and outs of PHP's oo syntax is not enough: "You must first choose the right participants for your system, and decide the best ways for them to interact." Now that's something you rarely get in a PHP book.
In Chapter 3, we begin to review the new syntax introduced in PHP 5; just to make sure we are all on the same page. One nice feature here is that Matt uses "sidebars" to point out everything that isn't available in PHP 4. This makes it easy to pass over if you are starting with PHP 5, but it also makes the information available for the rest of us.
It is important to note that this chapter gradually and effectively introduces the layers of OO syntax available in PHP 5. Each lesson or feature simply builds on the next. This makes it nice because you can stop, try things out, read some more, etc.
Chapter 4 takes us a little deeper into PHP 5's OO syntax. It is quite helpful that Zandstra breaks up Chapter 3 and Chapter 4. If you are new to OO syntax, the end of Chapter 3 makes a great place to stop and reflect for the night. Seriously, go to bed and let it sink in.
As you can imagine, the "Advanced Features" include concepts such as:
- Static methods and properties
- Abstract classes and Interfaces
- Error handling and Exceptions
- Final classes and methods
- Interceptor methods aka "Object overloading"
- Destructor Methods
- Object Cloning
- The magic __toString(): converting objects to strings.
These are not particularly easy topics to master the first time you hear them. However, I think Matt finds a great balance of code and presentation to get the ideas across.
His section on Exceptions alone should be required reading for anyone using PHP 5. Again, not only does he show what they do, he really explains how they will actually help you out.
By the time you get to Chapter 5, you are ready to learn a handful of tips and techniques you can use to keep yourself out of trouble. First off, as PHP is lacking support for true namespaces, Matt shows us the PEAR method of using naming conventions to avoid namespace conflicts. We also learn about using include, require and the new (and possibly controversial) __autoload() function. Of course, there are pitfalls with nearly all of this, and Matt makes sure we know them before we leave the chapter.
Finally he walks us through various reflection techniques. Naturally, starting with simple, function-based reflection. Then taking us through a very complete tour of the new class-based, Reflection API. If you haven't used this, it is a very clean way to expose every nook and cranny of your objects and classes at runtime. Something that can save your sanity in a language that lets you change your API on the fly. Again, it's not just a bunch of talk; there are plenty of great examples to get you there.
By the time you get to Chapter 6, it is time to take another break. Better yet, if this is all new to you stop and play with the code for a bit. Sure you could keep reading, but it will really help if you have the syntax and concepts down so you don't keep flipping back.
Again, Zandstra doesn't just jump straight into design examples; rather, he walks you through why you should even care. Sure, many of us have features in mind and run straight for the finish line ... but this can really get painful on older systems. He even takes a moment to point out one of the biggest traps for developers new to OO. "The presence of classes does not guarantee object-oriented design, even in languages like Java, which forces you to do everything in a class."
The chapter hooks you right away with an example done procedurally and another in OO using appropriate abstract methods. The point is clear: with proper design, you can get away from the Giant If-Else Blocks of Doom and pave the way towards actually keeping up with your client's requests.
Finally, he defines and relates the concepts of Responsibility, Coupling, Cohesion and Orthogonality.
Another great nugget of advice has been planted in this chapter. According to Zandstra, the art of selecting and defining objects "...is far more than just finding the 'things'" in a system. "If you see a class as a noun, a subject for any number of verbs, then you may find it bloating as on going development and requirement changes call for it to do more and more things."
Never before have I seen a simple sentence more completely dispel the inappropriate "object oriented" lessons you may have learned in school. If anything; if you find that it hits too close to home, you will pay attention to what he is about to say!
After telling a story about classes gone badly: "How should we think about defining classes? The best approach is to think of a class as having a primary responsibility, and to make that responsibility as singular and focused as possible. Put the responsibility into words." He continues, referring to the writings of Peter Coad: "If your sentence gets too long, or mired in clauses, it is probably time to consider defining new classes along the lines of some of the responsibilities you have described."
Our tour continues through the basics of polymorphisms and encapsulation. After which, Matt provides us with "four signposts" to help identify problems that can creep into our designs:
- Code Duplication
- The Class that knew too much
- The Jack of All Trades
- Conditional Statements
For more detail on these tell-tale signs that are probably represented somewhere in your code, go buy the book.
Matt really surprised me in this chapter. After getting us up on all the OO syntax and concept basics, he pulls out the UML. What was so surprising is how easy and approachable he made this introduction. In just a few pages, you learn enough to diagram and interpret inheritance, associations, aggregation and composition, and actually know what all that means. As an added bonus, he even gives a useful introduction to sequence diagrams.
Now, a chapter on UML (or some diagramming set) is usually included in any pattern book. But, this is different from those others. Matt provides s a short, easy to understand introduction to just enough UML to communicate your concepts and processes. A very cool bonus indeed.
Part III - Patterns As Matt says in chapter 1, this book stands on the work of giants. He makes this obvious in parts III and IV. While some may say that he is just repeating what others are saying, I would disagree. The value he adds in basing the patterns in examples you can actually picture writing yourself is worth every delicious page.
After walking us though the why-and-how of how "design patterns" came to be, Matt again makes us actually care about spending the time to learn as many as possible and to use them when it is appropriate. Again, he does a great job of breaking these tough concepts into bite-sized chunks. Don't get me wrong, though; you'll be full after reading the chapters in this section.
I won't go into great detail, but I need to at least provide you with an idea of the patterns you will learn about in this section.
In chapter 8, Matt describes some of the most low-cost, high-return concepts around: composition, decoupling, "patternitis" and the golden rule of OO development -- "Code to an interface, not an implementation."
In chapter 9 he introduces us to some "creational" patterns: The singleton, abstract factory, factory method and prototype.
Chapter 10 focuses on "structural" patterns. The ones he focuses on are the composite, decorator and the facade.
You should note, most of this is PHP written as if we were developing a civ-style, Web-delivered game. This is much easier for "the rest of us" to digest and apply these examples than the GoF's examples of building a large-scale word processor. No disrespect to the bible that is the GoF, but if you have read about design patterns, and still need a little help applying the ideas to your day job, parts III and IV were written for you.
Chapter 11 introduces us to some great task and message management patterns: Interpreter, Visitor, Strategy, Command and Observer.
Finally, Chapter 12 drives us home and provides us with a great look at even more great patterns and explains how they fit into the three tiers of sustainable web development: presentation, business logic and data retrieval and storage.
Presentation
- Registry
- Front Controller
- Application Controller
- Templates and Template Views
- Page Controller
- Transaction Script
- Domain Model
- Data Mapper
- Identity Mapper
- Unit of Work
- Lazy Load
Part IV - Practice This is a very important section: like the intro, please don't be tempted to skip it. Matt reminds us while learning code and code design is great, it teaches you nothing about the day-to-day tasks associated with actually keeping the project alive and kicking.
In "Borrowing the Wheel," he shares with us a fantastic piece of advice; one that many PHP developers could stand to listen to:
When this temptation [to reinvent the wheel] comes over me I remind myself of projects past. Although the choice to build from scratch has never killed a project in my experience, I have seen it devour schedules and murder profit margins. There I sit with a manic gleam in my eye, hatching plots and spinning class diagrams, failing to notice as I obsess over the details of my component that the big picture now is a distant memory (p. 294).
Please, take another moment to read that again. If this sounds eerily familiar, please stop reading my review and head strait for your nearest book dealer.
In these chapters we naturally get the (hopefully) obvious hints: use version control, write tests, use PEAR, etc. But, where else will you find all this along with excellent references on actually using PHPUnit2, writing your own PEAR Packages for managing even your own code, actual phpdoc syntax and examples ... not just the act of documenting your code, but using the phpdoc command line tool. And with the section on using cvs, you will have absolutely no excuse but to save your life with some form of version control.
Matt even devotes an entire chapter to managing automated builds with Phing, the PHP equivalent of Apache's ant or C's make.
Most of this information is available in countless forums, articles and websites where you could learn about all of these topics for "free." Or, you could read this section in an afternoon or two and begin amazing your friends and better managing your code right away.
Part V - Conclusions Matt's summary and overview is a great recap of the journey he has put us on. But, on top of that, he outlines some of the essentials that he had to leave out. Here he at least mentions the importance of tools such as bugzilla, mail lists and a wiki for all that other documentation.
Looking at the Bibliography (and all the places he gives credit where credit is due) is like looking at the reading list of nearly every great programmer. You will find books such as: Core J2EE Patterns, Design Patterns (GoF), Extreme Programming Explained, A Pattern Language, Patterns of Enterprise Application Architecture, The Pragmatic Programmer, Refactoring and UML distilled. This is, of course, along with many on-line articles and websites.
Sure, you could spend years reading all of these sources (and some you still should) but unless you get paid to read, do yourself a favor and get some of the best of all of these texts, tailored to you in PHP and delivered in just over 400 pages. My General Impressions
As I mentioned earlier, one of my favorite features of this book is that the examples are "real." This is not some collection of abstract examples like building the next great competitor to Word -- these are website concepts we mere mortals can relate to, such as product catalogs, games, invoices, and the like. You know, the stuff we actually do for a living.
This book does not cover loops, conditionals, functions, operators or any of the non-OO basics of PHP, and believe me, I am grateful. If you would like an introduction to the language of PHP, simply check out php.net or one of the many great introductory books.
I would certainly recommend this book (as if there was any doubt) to any PHP developer. This is especially true for anyone interested in learning more about using objects and classes more appropriately than ever before.
I would also recommend this book to any Java, Ruby or Python developer out there who hears the letters PHP in a sentence and immediately responds with any number of colorful phrases. As we have all read the Pragmatic Programmer by now, we know we can learn something from reading up on any language, and PHP has never been better than it is today.
Finally, I would tell any web application developer who is looking for a quick way to absorb and comprehend the meat of some of the best development and design books ever written.
Read it for yourself and I think you will agree: the desk of nearly every PHP application developer will one day be holding a copy of this book.
Daniel Holmes maintains the PHP User Group in Kansas City since its inception in 2000. He is also the Systems Integration Manager at JCCC in Overland Park, KS. You can purchase PHP 5 Objects, Patterns and Practice from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
Hmm...seems like an interesting book. Glad I learned the language last week. :)
the Spring Into PHP 5 book reviewed here earlier recently.
Want to know the best way to use objects in PHP?
use Perl;
*ducks*
WROX's Professional PHP 5.
This book sounds a bit more technical, but I've always loved WROX's style of writing.
The cat's in the bag and the bag's in the river.
In no particular order (other then that which appears on the front cover of Design Patterns), the Gang of Four is:
You pass as a programmer?
:)
Wow, you HAVE to know what you missed there. No idea? ";". Fool
Foxed Design
This book must be HUGE! Look how big just the review is!
Joking aside, thanks for the tip. I'm also always looking for good resources, and am a huge fan of PHP for development (especially after having to recently fix a hellhole of an ASP site). This comes at a good time with the impending release of a stable PHP 5. Thanks again.
Microsoft Sucks, F/OSS Rocks. I get mod points now right?
...for IBM developerWorks recently; here's his two part series on objects in PHP (part 1 and part 2).
If you like to write tech articles, I recommend dW; they're a good crew. Some of their tutorials (like my GLib collections tutorial) require registration, but, hey.
The Army reading list
why doesnt Daniel tell us how he really feels...
Don't ya hate it when the correct spelling of your favorite screen name is taken?
and I'll be modded troll again.
"PHP: Because 1,000,000 newbies can't be wrong."
- Someone, not me.
So how do you feel about "Holub on Patterns: Learning Design Patterns by Looking at code"?
And what about all the other patterns?
Glad we get our daily PHP book review here.
Hey, my job relies on my PHP knowledge, and even I agree with your statement. :)
PHP - Giving clueless webwhores the false impression they can "hack" or they understand basic principles of web-applications even before Rubile Off Roads.
I find very little use for objects when I write Php.
(except the very nice "smarty template" engine)
I don't know why, because I program with objects all day at work, but for web design, they don't stick around between page loads (unless I'm missing something, Ajax et all). I use sessions all the time though. I find procedural stuff much snappier than recreating the class each time.
http://www.zend.com/php/design/patterns1.php?print =1
You can get a taste of his writing skills which are pretty straight forward.
but just about everyone refers to that book as, well, The Gang of Four.
it's like the Dragon Book, but that's probably before your time.
sorry to burst your bubble...
Did you actually click on the goatse link? Never click on the goatse (or tubgirl) link.
There's a weird sort of backwards logic in your thinking there...
Yuck, short tags. Looks like you actually need to read the book :)
At this point if I were just starting out in Web development, wouldn't I want to invest in learning Ruby on Rails instead of PHP?
PHP had it's time. That time is now seems to be passing. For everything there is a time and a season: Now it seems to be the season of Rails.
For around 40 bucks
This book is also available for $26.39 at amazon.
<?
echo "who cares?"
?>
parse error on line 3
Don't be mad, PHP fanboi!
I believe every single one of the patterns mentioned above share names with patterns out of the book by Martin Fowler (and company): Patterns of Enterprise Application Architecture. I'm not sure I would be as unqualifyingly kind as the author of this review about regurgitating them. They are great patterns, but is a PHP-ized version of these patterns worth the price when it's such a major part of the book?
Troll? Maybe. I am getting slightly tired of all of the books around with titles like `Good programming practice in buzzword-language-of-the-week'. Good programming practice is good programming practice. It doesn't matter if it's in C, Smalltalk, LISP, or any other Turing-complete language - the concepts are the same. The only difference is syntax - some languages (and frameworks) support good practice better than others. Learning good practice in a way that is tied closely to a specific language will not make you a good programmer.
I am TheRaven on Soylent News
Actually, a closing ?> tag also serves as a ; That code is perfectly legal, albeit sloppy
My thoughts exactly. Learn how to really program well in a real language and never have to buy something like this again.
What is this PHP you are referring to?
</sarcasm>
Rails is only good for generating CRUD screens.
I've flicked through this book at work - overall it is a great book but it isn't the best book to learn Design Patterns with. I would suggest "Head First Design Patterns" by Freeman and Freeman. The examples are in Java but it should be fairly easy to port the patterns over to PHP (plus it will build up your experience with PHP5 Object-Orientated programming). You can find out more information about the Head First Series at Wickedly Smart.com
Well that's not what says my webserver. Since there's only one command to be interpreted you do not need to say to PHP "here's the end of this instruction, everything after that is unrelated." Therefore, you don't need it in that case.
Like .NET, preferrably C#. You know, something you'll use in the real world and get hired for. It's free, and it's much better than PHP.
Not All Who Wander Are Lost
Any good books you'd suggest for the task?
If you live in the san jose area, and you'd like to meet about PHP/Mysql, check out my post, and left a message. http://www.somejunkwelike.com/wordpress/2005/03/07 /south-bay-php-user-group-meeting/
I make these: http://beatseqr.com
Programming for the web is always a mix of multiple languages.
There are no compilers and debugging in a browser takes forever. Oh and all the compilers (read browsers) give completely different results because they are buggy. When was the last time you used a C compiler with bugs that caused more than a performance hit?
Give me C/C++ and a make file and I will produce nice clean code.
Doing the same in the combination of PHP/HTML/JS that is the web is much much harder.
Hmm, really?
:P
Well, slap me silly, I should know that
Foxed Design
It's not that hard, man..
> What does the acronymn PHP stand for ?
:)
I've been told that it stands for "Poorly Hacked Perl", but somehow I doubt that, no matter how appropriate it may seem.
PHP's author never envisioned it becoming a mainstream language. It tied into Perl to do its processing and had some massive security holes. There is a surprising amount of hate filled FUD surrounding the language these days (???) but an objective look at the modern PHP language/platform will show it suitable for a broad range of web applications. Perfect? Hardly. But wonderfully pragmatic for most everyday tasks.
Good design and OO will only help those who have more serious needs. In that vein I would love to see future versions focus on scalability (yes, I do realize that Yahoo runs on it but not without some serious configuration) and perhaps persistance?
Fortunately there's lots of great development tools and when PHP fits, I say use it.
First off,
Correct code:
<?PHP
echo 'Who cares?';
?>
I'm not going to mince words. I think that if you have a book on Java, it really only applies to Java. Anyone can claim a book will apply to other languages, but some differences could cause confusion and hours of lost productivity. I might read the book you suggested but I wanted to make it clear that I would be only reading it in terms of Java and not PHP. Mixing languages is what causes so many compsci students to skip class and play Quake.
The dangers of knowledge trigger emotional distress in human beings.
ativity in here? what gives? - if you dont like the review, php or life in general please give some intelligent reason as to why.
I thought there was a higher level of respect at slashdot... guess i am showing my n00b.
If you'd really like to upgrade your programming style, why try a real book?
I see so much stuff about writing better OO code, better Java, better PHP...hardly much at all about changing the way you think about programming. I know it's written about Lisp, but it's a book about high-end coding - about what being a master at code is all about.
Free download here.
Tired=RoR
Expired=PHP 4
Get with the program already:-)
Oh lord, i'm feeding the troll...
Oh and all the compilers (read browsers) give completely different results because they are buggy.
Your browser is most definitely not comparable to a compiler, especially in the case of PHP. PHP is interpreted on the server side, and you never see what was scripted. I "compiles" what could best be compared to a bytecode, that your browser executes, in a semi-standard way.
It's like a java app, in a way. What gets delivered to the user is the same (the bytecode), but theres slightly different widgets (rendering quirks). (Just to put this out there, I don't know if that's actually the case, I just assumed it would be)
By the way, anyone who's a good "programmer" would not mix html and javascript up in their PHP. Always separate logic from presentation.
Beware that if you plan to run PHP5 on a large scale, you really need to buy Zend Platform ($1500 per multi-cpu server). Running a large application without an opcode cache requires ALOT more memory, and the free opcode caches (apc and eaccelerator) do not optimize PHP5's new object syntax well, if at all. Do some simple testing on such an app with memory_get_usage() or a debugger and you will quickly see what I mean.
.NET, which I think is a nicer framework. Too bad I don't like windows as a server.
I was looking at PHP5 as a platform for a rails-like MVC framework, but it would cost over $15,000 in licensing for it to run on our cluster on the scale we need. The free accelerators are finicky and questionably stable. I do not trust them yet, though I'm sure they'll improve. We decided to go with mod_perl and Catalyst with custom model classes as a framework.
Frankly, Zend makes me nervous (it took two weeks to get a response to a sales inquiry). If I were to spend this kind of money it would probably be on
At any rate, be careful.
At this point if I were just starting out in Web development, wouldn't I want to invest in learning Ruby on Rails instead of PHP?
I've been thinking about this too, but PHP seems to win hands down in the deployment category. It looks like a lot of Rails apps use lighttpd, but a lot of people are very happy with Apache.
You can use mod_ruby, but this gets tricky with multiple applications on the same server instance. The "preferred" deployment method seems to be FastCGI, but this seems like a strange option to me. I worked with FastCGI at a 4 million+ member site, and we were happy when we were able to leave FastCGI behind. It ate up gobs of resources. Maybe things have changed since then?
Another area that's a bit more grey is syntax. Ruby has all sorts of special syntax, some of which is quite clever, but one person's "clever" is another's person "bizarre." Probably not quite as vexing as Perl, though. For better or worse, PHP doesn't have much special syntax. Personally, I think this is good.
Finally, I've found PHP to be unbelievably fast. There's been dozens of instances where I was sure I'd have to spend time optimizing an application, but was proven wrong. Your mileage may vary, of course.
There's a lot that Rails does right, but I'm not yet convinced it's the only reasonable optional for medium-sized apps. Of course, this gets a bit muddle because we're really comparing a framework to a language.
Scott Stevenson
Tree House Ideas
All you programming geek-a-stupids have one thing in common... y0u all masterbate, using your mother's underware, at different frequencies.
what'd i'd really like is a perl book on the same topic...does anyone have suggestions?
-Bucky
If you really cared about OO design and good code you would not be coding in PHP but Java, .Net or C++. PHP is just not suited for real-world web applications. Rather read The Pragmatic Programmer than a book about a specific language.
The patterns are not the same for all languages. If you program assembly language you would use patterns for things like sub-routine creating/calling/exiting.
Likewise in C, which has sub-routines built-in, you would probably have patterns related to creating an OO flavour. Instance pattern, inheritance pattern, method call pattern etc.
So if you think that these books are all the same, perhaps you have grown out of the level of computing C/Java/C#/C++/Smalltalk offers and are ready to take the next step. Perhaps CLOS in Common Lisp or Prolog can be a good start?
did they say they was mixing logic and presentation? Nearly all websites these days require a combination of a server side language, browser side and obviously html. Other than that you pretty much agreed with the post.
Pretty Homo Programming.
The Zend Optimizer (ZO) is not a bytecode/opcode cache. The ZO injects itself into the processing of scripts and will allow the Zend Engine to decode Zend encoded files. It will also try to optimize the compiled bytecode. It's this second step where the performance gains can be seen, in some cases.
However, without a code cache of some sort, the optimization steps will be run on every request. The ZO will cache the results of the optimizations, which is the optimal way to go about it.
Example:
You have a script which takes 50ms to execute. ZO can take 15ms to 'optimize' it down to 40ms of execution time. If the optimized code was cached, then every further execution of the script would take 40ms - a 20% speed up. But you're only getting that 20% speedup at a rather extensive processor hit. It's not worth it, so the ZO can actually slow down some code (especially if you're already gone through an optimized your code by hand). The ZO also doesn't even attempt certain types of internal optimizations unless the Zend Cache is present because it knows some of these analyze/optimize cost/benefit ratios just make *no sense* ever.
The ZO is a mixed bag, and I've rarely seen it do anything noticeable in the past few years. It consider it more just a way for them to seed the market to make it more attractive to use the Zend Encoder. Not that that's a bad thing - I'm not criticizing them for it. It's just that the real performance boosts come from opcode caches. Any code that gets a significant boost from ZO alone was probably written very poorly to start with and could be mostly fixed by hand in the PHP source directly without requiring an external helper app like ZO.
creation science book
I was implying that the server-side portion of things shouldn't be mixed with the client side of things. That basically means, not mixing your PHP throughout your html/js. I fully agree that folks will work with all three, but they shoudl never work with more than one at a time.
Are we talking server/client or logic/presentation?
As long as logic is clearly seperated from the presentation i see no problems in having server side code mixed in the html/js as long as it is for presentation.
Maybe i am misinterpreting what you are saying?
You can't post an article even vaguely about PHP without /. idiots replying with "OMGWTF PHP, l4m3!!111"
you got us, we're pwned, good work. the sad thing is, you WEREN'T modded troll. And you had 3x the "funny" that you did "flamebait" "redundant".
The solution?
m s-0.8.11.tgz
# assuming Ruby is installed..
wget http://rubyforge.org/frs/download.php/5207/rubyge
tar zxvf rubygems-0.8.11.tgz
cd rubygems-0.8.11
sudo ruby1.8 setup.rb
sudo gem install rubygems-update
sudo gem install rails
cd ~
rails goodbyephp5
cd goodbyephp5
script/server &
lynx http://localhost:3000/
# woo!
Robby Russell
PLANET ARGON
Robby on Rails
I was implementing some coding algorithm that required using an unsigned int. Believe it or not there is no way to create or use an unsigned int in PHP (I even tried "faking it" by twiddling the most-significant bit of a signed int by ORing with a known value, but I just couldn't fool it)... but Ruby has that capability. So I successfully implemented the algorithm in Ruby, really started to like the features of the language a lot ("everything is an object" is actually pretty nice; data that comes from the outside is automatically flagged as "tainted"; blocks; some neat features borrowed from Perl and Smalltalk; mixins vs. multiple inheritance etc.) and next thing I knew I didn't want to write any more PHP.
/usr/bin/ruby when googling finally revealed the answer- Ruby was trying to protect me from unvalidated input! All I had to do was object.untaint and it would trust me. Oooooooh, I said, that is cool! (even though it bit me in the arse at first)
The "tainting" concept in particular was pretty revealing. Ruby will not only "taint" any data that comes from the outside (web forms, etc.) but also any objects that touch that data. I was kicking myself trying to figure out why I kept getting security errors, I was about to delete
There are many aspects of the language like that. And there are also many aspects of RoR like that.
I know it's just M.H.O. tho, but if I were to be a betting man, I would put my money on Ruby (carried by Rails) as the next up-and-coming enabling scripting technology. I haven't built anything large-scale with it yet, but I have found it very enjoyable to build the things I have so far.
The lack of a huge installed base is just a temporary setback. If this is one's prime motivation, then everyone should just stick to Microsoft ASP and forget about any alternatives.
Wow, you really haven't played with it much. Have you?
Robby Russell
PLANET ARGON
Robby on Rails
Finally, somebody who realizes that Rails is good for the low end. It competes with PHP, not J2EE and .NET.
I've used Rails for a year and used Ruby to some extent in over 50 large-scale commercial projects. I don't "play" with software.
I got this book about 6 months ago, and found it VERY helpful. At that time, I knew PHP and knew some simple OOP, but didn't know much about patterns or class design. Seems to me there are probably LOTS of PHP coders out there in a similar position, who are just looking to improve their existing practises and apps, and don't necessarily have time to learn C++ or Java just so they can read the Gang of Four book (or others of that sort) with much hope of getting anything really useful from it.
After reading Zandstra's book, not only could I use PHP classes and objects much more effectively, I was also able to give *Design Patterns* another try and actually make some sense of it.
Your average slashdot poster is more likely to be satisfied with OOP brochure-talk than, say, the more academic types over at LtU.