PHP In Action: Objects, Design, Agility 232
Michael J. Ross writes "Despite being perhaps the most popular Web language in use, PHP has for much of its history been criticized for not offering the full capabilities of object-oriented programming (OOP). But with the release of version 5, PHP introduced a robust object model, and made it easier for its proponents to create well-architected Web sites and applications. In turn, the new OOP capabilities have facilitated additional best practices, such as design patterns, test-driven development, continual refactoring, and HTML templates. These topics and more are explored in the book PHP in Action: Objects, Design, Agility."
Authored by Dagfinn Reiersøl, with Marcus Baker and Chris Shiflett, the book was published on 3 July 2007 by Manning Publications, under the ISBNs 1932394753 and 978-1932394757. Its subtitle accurately reflects the major themes of the work: creating PHP applications built upon objects, utilizing Web-oriented design patterns, and incorporating agile programming techniques such as refactoring and test-driven development. Also covered are methods for effective form handling, database extraction, date and time representation, and more.
PHP in Action: Objects, Design, Agility | |
author | Dagfinn Reiersol, Marcus Baker, Chris Shiflett |
pages | 552 |
publisher | Manning Publications |
rating | 8/10 |
reviewer | Michael J. Ross |
ISBN | 1932394753 |
summary | A pragmatic guide to object-oriented PHP development. |
As a result of trying to adequately cover such a large number of major topics in a single book, the amount of material is considerable, and the book is certainly longer than the typical Web programming book in general, and PHP book in particular. Spanning 552 pages, the material is organized into 21 chapters, grouped into four parts: In Part 1 ("Tools and concepts"), the authors discuss PHP 5, its strengths and weaknesses, and how well it can be used with advanced programming principles; an overview of objects, exception handling, and references; visibility, abstract classes, and interfaces; effective use of classes and object-oriented design; inheritance, composition, and more on interfaces; advanced object-oriented principles; six design patterns that are especially appropriate for Web-based systems (Strategy, Adapter, Decorator, Null Object, Iterator, and Composite); and lastly, date and time handling using objects.
For developers well-versed in OOP, Part 1 may be more of a review, while Part 2 ("Testing and refactoring") could be the most valuable portion of the book. In the four chapters, the authors dig into the details of test-driven programming, refactoring, and Web testing. These chapters and all that follow take a very pragmatic approach to conveying ideas, which is consistent with the theme of Manning's "In Action" series, based upon the idea that programmers tend to learn best by reading sample code instead of generic discussion. For instance, test-driven development (TDD) is demonstrated by showing how to implement database transactions, a contact manager, and e-mail functionality. Mock objects and top-down testing are illustrated through the creation of an e-mail class, and further extended with a discussion of faking the mail server. Given that testing is the primary theme of the entire part, one might expect a more lengthy discussion of TDD, but Reiersøl correctly notes that this particular book is not trying to replace the many manuscripts and articles already published on agile development; also, the database examples adequately demonstrate the general principles discussed prior. The chapter on refactoring is well worth reading, and touches upon the controversial topic of how much one's PHP code should be separated from the HTML code — a topic later revisited in the chapter on templates. Also explored is a topic critical to maintenance programmers — refactoring versus rewriting. Two different testing frameworks are discussed, PHPUnit and SimpleTest; the latter is used throughout the book. The final chapter in this part explains how to test Web pages programmatically, by faking interaction, and other techniques. The chapter ends with a section providing steps on how to deal with "the horror of legacy code," when the unfortunate programmer has inherited a nightmare of a live Web site.
The third part of the book, "Building the web interface," begins with an examination of templates, the arguments for and against them, and three of the most commonly used template engines: Smarty, PHPTAL, and XSLT. One of the previously discussed design patterns, Composite, is utilized for combining templates to create complex Web pages. The chapter on user interaction makes use of the Model-View-Controller architecture, with the subsequent chapter delving deeper into the topic of controllers for Web pages. The next two chapters cover an area of site development that is a frequent cause of uncertainty, "bandage coding," and security risks: user forms and input validation. The book's coverage of the PEAR package HTML_QuickForm, alone makes it worth reading. Part 3 concludes with a chapter on abstracting database resources through objects and the Singleton pattern.
The fourth and last part of the book ("Databases and infrastructure") is relatively brief, comprising two chapters on marrying SQL with object orientation. The authors present a number of techniques for shoehorning SQL transactions into object-based code, including encapsulating queries inside of methods, building SQL statements dynamically, substituting SQL elements such as column and table names, using SQL aliases, and using SqlGenerator.
It is clear that the lead author, Dagfinn Reiersøl, has put a tremendous amount of time (three years, as noted in the preface) and effort into creating this work. The discussions are wide-ranging and in-depth, and there is just enough sample code to illustrate the ideas being discussed and also break up the visual monotony. The illustrations are limited in number, and consist mostly of class diagrams and UML sequence diagrams. Overall, the treatment of each topic clearly reveals that he has considerable experience with them, and has given thought to the pros and cons of some possible approaches, though not all of them.
However, there are still some weaknesses in the book. For example, in all of the material discussing how to separate the SQL code from the PHP code, I found no mention of stored procedures, such as those made possible in MySQL. All of the sample code appeared to be solid, though there was no clear reason for the inconsistent use of print() versus echo() is different code samples. All of the chapter summaries could be excised without any loss of value, and many of the chapter introductions could be eliminated as well or condensed.
On a more mechanical level, the book had many minor weaknesses: It was not encouraging to see the first erratum even before reaching page 1: "raising own level" on page xix, in the second paragraph. Readers may initially be confused by such attributions as "Uncle Bob [Uncle Bob]" (on page 77). In a future edition, it should be explained that names in square brackets are biographical references listed in the Resources section, which follows Appendix B. In the first sentence in Chapter 12, the reference to "Jackass" will probably be confusing to many readers — particularly non-Americans — and is not in the best of taste. In the text and the table of contents, the chapter and part titles are written in sentence case, instead of title case, for no obvious reason. It is not clear whether this is meant as an unsuccessful attempt at literary hipness, or just an unfortunate reflection of the current text messaging generation, which is eschewing rules of grammar that for centuries have made text easier to read. Finally, there was one problem in the production of the book, and not its writing: Several of the pages had light brown spots on them that were apparently part of the paper, and not a result of post-production staining. But these may be limited to my particular (brand-new) copy of the book.
Readers interested in learning more about the book could start at the publisher's Web page, which features an online table of contents and index, all of the book's source code, two sample chapters (7 and 21) in PDF format, and a link for purchasing the electronic version of the book, also as a PDF file. Any road/code warriors who do development on their laptops, on the go, will appreciate having this book readily available.
Yet most of these objections are minor and easily fixable, and do not detract from the value of this book. I especially liked the depth of experience brought to each topic, and the authors' consideration of differing viewpoints. PHP in Action is a competent, engaging, and detailed discussion of object-oriented and agile programming principles that can help PHP developers boost their effectiveness and the quality of their code.
Michael J. Ross is a Web developer, writer, and freelance editor.
You can purchase PHP in Action: Objects, Design, Agility from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
3.... 2.....1.... (Score:5, Funny)
Re: (Score:2, Funny)
Discuss.
Re: (Score:3, Funny)
Re:3.... 2.....1.... (Score:5, Funny)
Re: (Score:3, Funny)
Re: (Score:2)
Re: (Score:2, Funny)
Java bytecode is good for quick prototyping of web portals though.
Re: (Score:2)
Re: (Score:3, Informative)
http://www.keplerproject.org/wiki/US/HomePage [keplerproject.org]
Re: (Score:2, Insightful)
Looks like a great book if you're stuck with PHP (Score:5, Informative)
Stuck? (Score:2, Insightful)
I've been using PHP for eight years and there hasn't been a day where I wished I had chosen another language. Sure, I wish the PHP of today was available eight years ago, but I can't complain with
I've said it before and I'll say it again: (Score:3, Funny)
Re:Stuck? (Score:5, Interesting)
Re:Stuck? (Score:5, Funny)
I've been praising GWB for eight years and there hasn't been a day where I wished I had chosen another president. Sure, I wish the economy of eight years ago was available today, but I can't complain with what is available now.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Search terms: clinton economics
Clinton Economics [nationalreview.com]
Enjoy.
Re: (Score:3, Insightful)
Yes, all things that are popular are good and work well! Windows 3.1 and Visual Basic were very popular. So was the belief that the earth is flat. And there's chlamydia. That's hella popular.
I've been using PHP for eight years and there hasn't been a day where I wished I had chosen another language.
No offense, but if you've been using the same language for eight years without any regrets, I don't see y
Re: (Score:3, Informative)
So my career path, which lead to developing in a specific language, has somehow excluded me from being eligible to offer up any "useful information"? Where is the logic in that?
As far as I can tell, PHP is popular because it's perfectly adequate language for cranking out some basic dynamic pages, and it's very easy to learn and s
Re: (Score:2)
No, I don't need to argue that.
My point is that you should use the right tool for the job. The guy I replied to is one of many people who only has one tool in his toolbox: PHP. In my view, that makes him either a novice or a dolt. I'm ok with novices: they know they need to learn more, and eventually do. The dolts, on the other hand, are beyond my power to help.
Are you sure you understand? (Score:3, Interesting)
function a() { new DateTime('2007-02-32'); }
function b() { a(); }
register_shutdown_function('b');
And even then my complaint isn't that you can't do that, but that there is absolutely no way to track down the source of that error because unlike most other PHP errors, you're told it's on line 0 of Unknown.
PHP5 (Score:5, Interesting)
I do web development & design for a living. I use PHP because it is what I got into and I have not yet had the time and/or drive to really try anything else. PHP is so available and that is its real strength. It's biggest problem is those lazy folks who are still running 4.2.x or some branch that is or is to be discontinued very soon here. As well there are some known exploits and issues in the older branches.
I love the rapid-ness of PHP though. At present I even use PHP-GTK2 to prototype all of my idea's while I learn new languages. That is, I'll make a rough draft in PHP-GTK and then try to do the same in C/C++... which is much more painstaking for someone who has used web development for so long. But I am slowly un-learning my habits to depend on magic to handle memory for me, etc.
Yup. Just my random bablings.. I am sure there was a reason I started writing this comment.
Re: (Score:2)
You kind of contradicted yourself there. That, or PHP is much more pervasive than I give it credit for, such that even the 5.2.x branch is more widely deployed than everything else... but I kind of doubt that.
Re: (Score:2)
Agreed. Even PHP developers should know about memory management. I use PHP all the time, I love it. But it can be just as dangerous as any other language. Functions like file_get_contents() are extremely convenient but also extremely stupid. It's kind of similar to C's strcpy() (only it won't cau
Re: (Score:2)
Or maybe they need to learn to be a coder.
You were born less than a toaster operator. You were born a smelly infant who couldn'
Re: (Score:2)
I don't quite see the contradiction there, perhaps it was the way I worded it? What I meant to get across was that PHP 5.2 is the current stable branch and that there are some hosts out there that are still strictly only PHP4... despite some of the security issues.
Re: (Score:2)
True, but it still contradicts the point you made that it's "so available". Maybe it's how I'm reading it, but I took that to mean that every cheap web host in the world is going to have PHP somewhere -- but that's not much of a strength if you're counting all the PHP4 hosts in that statistic.
Re: (Score:2)
Re: (Score:2)
Change Log: http://www.php.net/ChangeLog-5.php#5.2.0p [php.net]
Upgrade Guide: http://www.php.net/UPDATE_5_2.txt [php.net]
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Did you even TRY to look for it yourself? I haven't used PHP in years either, yet I just went to php.net and right there in the second news entry on the front page, it announced 5.2.5 is released, and contains a link for Changelog for PHP 5. Boy that was hard.
Re: (Score:2)
Re: (Score:2)
PHP's advantage is an easy learning curve, so it is easy to pickup (no cheap jokes about fat women, please). Larry Wall described [perl.com] that as [
Re: (Score:2)
Which is funny, b
PHP needs more work (Score:5, Insightful)
Re:PHP needs more work (Score:5, Informative)
Re:PHP needs more work (Score:4, Informative)
Re: (Score:2)
Re: (Score:3, Informative)
Another workaround is to just use a temporary. Or a different language outright.
Re: (Score:2)
This is usually pretty useful (in web design anyway) for configuration... as it is read only. If you need write, then what was the point of putting it in a function?
Re: (Score:2)
should have been:
$get != chr(7)
Re: (Score:2)
But, of course, SNOBOL4 was actually designed, and it had an "item(array,index)" function to correct this defect... I am sure that PHP *must* have something equivalent? (I am actually interested in the answer -- I am assuming PHP DOES have a solution that won't involve additional variables),
define('foo()')
* because "output = foo()[1]" won't
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Why shouldn't it work? Yes, I'm lazy - I don't want to write an extra line in and have to think about a new name for a temporary variable, when I don't actually need the variable.
I can't count how many times I have code like this:
Re: (Score:2)
Re: (Score:2)
<?php
function f() {f();}
f();
?>
t@t ~> php test.php
zsh: segmentation fault php test.php
I had some fun with that when I accidentally introduced it while developing, and the webserver suddenly kept serving up blank pages.
PHP catches almost all other kinds of user errors, and shows a nice error message, but when I reported this one they referred me to the manual and marked the bug report BOGUS. I still maintain that the interpreter crashing is not expected behaviour.
yeah right (Score:3, Insightful)
Seriously, it has nothing to do with the fact we're sick and tired of cleaning scripts written by people who don't know what they're doing, and we like blocking access to your site for major vulnerabilities. We actually love it how when your script gets owned, you don't notice for months because you do the development on the server, all the while jerkoffs are udp-flooding from your site. Because you'll never pay for this usage, and you'll expect us to fix your script, it doesn't matter because we're just really upset that it isn't "offerring the full capibilities of object-oriented programming".
That and we sometimes wonder what it would be like to fling poo...
Re: (Score:2)
Well, there's always the option of becoming a Perl developer.
Re: (Score:2)
Sure, and those are all valid complaints.
Yet PHP continues to be used by some of the most popular sites. Why is that?
I think because PHP *is* easy and approachable, and so when some guy has an idea for something he just starts building it. He doesn't have to hire a Java programmer at $80K a year to tell him how his idea is not going to work.
Re: (Score:2)
Worse is better [jwz.org].
That's an interesting way to look at it.
I would look at it differently: If I wanted to be successful, would I use the same tools that all those unsuccessful people are using? Or would I use the
Re: (Score:2)
Then you don't know very well. allow_url_include [php.net] was introduced in php version 5.2. All versions prior to that (Except versions earler than 4.3.0 on windows [php.net]) in fact operate exactly as I specify.
Only completely not [google.com].
Re: (Score:2)
Got a reference for that? From the php manual:
Where to start out language wise? (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
If you have nothing but brains and time, C will be a great start...managing references vs. pointers and memory...you will be bulletproof when you start using a 21st century language. Not to start a flamewar here, but maybe it's useful in plenty of ways (mostly learning how freak
Re: (Score:2)
Re: (Score:2)
If you don't know HTML, Javascript CSS learn them First.
I'd certainly consider PHP as a good starting point...Why?
- You can easily play with PHP on most Linux distribution without any difficulties. Most of the time PHP is part of the default web server package. (same for Perl but usally it requires additionnal installation like DBI if you want to play with database)
- Syntax is quite simple and almost as flexible as Perl (almo
Re: (Score:2)
Stop looking at languages that way. They aren't like spoken languages- you cannot realistically speak one well enough to make up for the fact you can't speak any o
"robust object model??" (Score:5, Insightful)
While I agree with the latter overall, I dispute "robust object model." What's missing? Polymorphism is sketchy, and static initializers are missing, for two. In PHP5, you can only initialize static properties with literals or constants - no function or method calls.
Also, calling up the inheritance chain, to a grandparent class's implementation of a method, is difficult to say the least.
While PHP5 is a *lot* better than PHP4 (and probably Perl if one took the time to compare) - it's not really comparable to truly robust OOP languages such as Java, Smalltalk and C++.
Mind you, I code in PHP5 for a living. It gets the job done, but it has to be called on its limitations, and you gotta be honest and tell programmers who want OOP from PHP5 that it has limits, and how to work around them. None of this "robust object model" stuff.
Re: (Score:2)
How is it better than Perl?
I'll admit Perl's OOP is weird. It's weird syntactically, it's weird conceptually, it feels bolted on, etc.
But scratch the surface a bit -- it's also every bit as powerful as Java or C++. Moreso, I'd say, especially if you like "duck typing" (to steal a Ruby term).
Re: (Score:2)
For coding, I find PHP5's syntax clearer - verbose keywords are the key, for me. For usage, I find Perl's better - simply require/use a module, instantiate, use, etc. Plus, the CPAN archive of modules and classes is outstanding.
However, I feel about Perl's OO the way I feel about Javascript's - it's syntactically weird, as you say, and not verbose enough for me. Too much implied through context and operators, not enough spelled out. That said, I tough it out and work with 'em both.
For Javascript, sy
Re: (Score:2)
Too much implied through context and operators, not enough spelled out.
There's nothing stopping you from being more verbose in perl.
For example I typically write my plain functions like this:
While I could have easily gotten away with:
which actually turns out to be faster but not very easy for the unexperienced to read or maintain.
As such I reserve non-verbose and awkward code for special situations (needs optimization, needs to go fast) but I tried to be verbose
Re: (Score:2)
sub add {
my ($x, $y) = @_;
return $x + $y;
}
However, the one-line example you listed is the kind of thing I might use as a callback. Sometimes, I just can't resist overly-clever, completely unreadable one-liners.
Re: (Score:2)
I come to bury PHP with a backhoe, not to praise it, but: why on earth does it actually need static initializers? PHP code runs as a script. You just stick the initialization code in the script.
Re: (Score:2)
Haha - well, that's a good point, but one I won't concede due to my long-lived habits. =)
Some static properties you only want to initialize once, and they're not singletons or the like, so you don't necessarily want to trigger their initialization through the constructor. I suppose you could wrap the static initializer code in another static method, then call that method from the bottom of the .php file that defines the class. I have a recollection that there are problems with that.
Re: (Score:2)
As a long-time OO programmer who has been baptized by fire over the past two months in PHP, I strongly concur with your sentiment. PHP is another good tool to have in the tool box, and the OO is decent but a little short of full-blown. Your suggesti
That's not why it's been criticized. (Score:5, Insightful)
Nope. PHP has been criticized for:
I could go on. Not all of these are really legitimate complaints, or a reason not to use the language; indeed, it has evolved. Due to the amount of code that exists in PHP, and the amount of cheap hosting which runs some form of PHP, I can no longer accuse people of being stupid for choosing PHP, although I might call them insane for liking it if they've given anything else half a chance.
But I wouldn't put a lack of basic OOP particularly high on the list, especially with how dysfunctional the OOP was when it was finally added.
Disclaimer: As much as I enjoy flamewars, and although I realize this will feed one, that's not why I'm posting. I'm just posting to clarify -- if you thought all PHP needed was OOP, you're dead wrong. If you're trying to improve PHP, look beyond OOP. (Look especially to the mysql_add_slashes_no_really_i_mean_it_this_time() functions, and compare them to Perl's support for prepared queries.)
Re: (Score:2)
The annoying thing is though that the function will not get cleared from memory once if goes out of scope, making it leak memory. great.
Re: (Score:2)
http://us2.php.net/manual/en/function.mysqli-stmt-prepare.php [php.net]
Looks pretty much like PERL's version
http://articles.techrepublic.com.com/5100-3513_11-6139247.html [com.com]
Re: (Score:2)
I should have been clear -- a lot of the criticism of PHP is for historical reasons. But they are kind of valid historical reasons, because a lot of people do still code like that.
But you can probably build a decent API on top of most Turing-complete languages.
Re: (Score:3, Informative)
Re: (Score:2)
I don't see that as a problem. Or at least, the problem there is that those variations are in PHP.INI, which isn't exactly accessible to the application developer.
Take Ruby -- as I've been re-learning Ruby for work, I've also had to learn Rake and Capistrano, both of which can be seen as mini-languages built on top of Ruby. This is a feature, not a bug -- plus, no one is forcing me to use Rake, even in a so-called Rake script.
Re: (Score:2)
Be Aware, PHP behind !!! (Score:2, Insightful)
Re:Be Aware, PHP behind !!! (Score:5, Interesting)
Publisher web site (Score:3, Informative)
The publisher link in the article should have been: http://www.manning.com/reiersol/ [manning.com]
Thanks in advance
Want Real OOP Evidence (Score:3, Insightful)
I've never seen good examples of OOP making websites or typical business clearly better. Any bad non-OO coding presented was merely poor knowledge of procedural, bad specific languages, or lack of knowledge about good relational techniques. I challenge anybody to clearly demonstrate OOP being better for the mentioned domains.
I've found flaws with the OO books out there. For one, they assume unrealistic change patterns to artificially boost OO. And please no anecdotes; for those are not dissectable. If OO fits your own personal psychology better, that's fine, but I don't wear your head.
Re: (Score:2)
2) understandability
3) code reusability
4) loosely coupled code
5) modular code
If you don't understand how these can be helpful in business and heavy web applications, you've probably never worked on one with a team before..
Re: (Score:2)
Yes, I agree, as a concept, well written OO can provide those things that you mention:
1) maintainability
2) understandability
3) code reusability
4) loosely coupled code
5) modular code
Then again, *any* well written code provides those things. What we see, however, is ever growing heaps of interdependent class libraries who's periodic API deltas cause
Re: (Score:2)
2) understandability
This actually is a result of a self fulfilling prophecy of sorts. No one, to my knowledge, has ever demonstrated that OO was inherently more understandable than other methodologies. But I do not dispute your point in the context of the other points you bring up, for in a sense, it is true.
The reason...
It appears to me that colleges all bought into OO. And so they churned out a vast number of graduates who all spoke the OO language. And so if you hire people,
Re: (Score:2)
OO on a basic level is more difficult to understand than a procedural equivalent
That's probably true. But a nail gun is also more complex / difficult to understand than a hammer. The reason it's chosen as the tool of choice by professional carpenters is that it's much more powerful.
OOP does seem to be a double-edged sword, though. While well-written object-oriented code can be substantially easier to read and understand than well-written procedural code, badly written OOP code can be harder to understand and more complex than badly-written procedural code. So no, it's not exactly
Re: (Score:2)
Please show me a single example in the domains mentioned.
PHP and the web (Score:5, Insightful)
For what it is, PHP is pretty good, a quick and dirty scripting language that, if used right, can make some pretty impressive applications.
The real problem with PHP is the bickering and infighting little boys club that is the PHP development community. Over time they've learned a lot, but for the most part they believe they know everything and everyone else is wrong. Even though there are public forums, decisions are made on IRC chats. It is not as transparent or well functioning as groups like Apache, PostgreSQL, and others. A lot of petty crap goes on behind the scenes and a lot of people who would have been active contributors get pissed off and leave.
I could go on with first hand and second hand stories and it is my opinion that it is this lack of professionalism that hinders PHP quality and adoption on an enterprise level.
All that being said, PHP has a solid purpose in the web world. Java and
PHP is a fine language (Score:2, Insightful)
Re: (Score:2)
There are stories here that make you wonder, but IMHO this isn't one of them.
Re: (Score:3, Informative)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Recursion is not used often enough to make a difference. If you use a lot of recursion, you'd probably prefer Lisp.
Many PHP-modules are not thread safe
It's not a common need unless you are doing something odd. If you put every pet feature into a language, it becomes a bloated mess.
You might think PHP is free and all PHP-modules in the manual are free too. Wrong. For example, if you want to generate a PDF-file from PHP you will find two modules in the manual: PDF or ClibPDF. But both come w
Re: (Score:2)
OOP is not complex (although some languages that use it are), when
implemented well it makes life simpler.
Once you really get OOP under your skin, programming without it
feels like a work-around, even for tiny projects.
Re: (Score:2)
There are some unusual ones that are nice to have, but most are in fact equally well covered in other languages' standard classes, and would have been better to support as class methods than global functions.
The main reason _I_ sometimes use it is that I _know_ I will be able to deploy it at whatever ISP I might decide to use. And that there is extremely little overhead with starting to toy with a new project compared to many
Re: (Score:2)