PHP In Action VS PHP Objects Patterns and Practice (1)

First of all, both of them are very good books. They are the only books I've seen that focus on software development methodology instead of PHP language features. Even an experienced PHP developer should take some time to read through them (or at least one of them).

Both of these books are organised in three parts: 1. PHP Class, Objects, OOP design; 2. Design Patterns 3. Testing and other practice such as version control, refactoring.

For people who have any experience of C++ or Java, the first part of the books may be safely skipped. However, pure PHP programmers, especially those still using PHP 4, better read through the first part.

Second part of these two books are most valuable to PHP developers and worth careful reading. Each book introduces some design patterns. Some of these patterns are introduced in both books. The others could only be found in either one of them. PHP In Action uses one chapter to explain six design patterns, the other book spends 5 chapters in presenting 10 design patterns. Personally, I think the second books presents design patterns in more details.

Both books have chapters about database patterns, unit test. PHP In Action also introduces some concepts of refactoring while the other book uses a whole chapter to show us enterprise patterns and it also introduces other PHP development practice such as CVS, Pear, etc.

As I said, both of these two books are good and worth your reading. However, if I have to pick up one winner from them, i will choose PHP Objects Patterns and Practice. Compared with its competitor, it digs deeper and explain more details.

Notes of reading PHP In Action

I start to read a book PHP In Action. I think this is a great book for PHP developers. Below quoted from the book really impressed me.

Page 38,
"The traditional alternative is typically to emphasize up-front design. The idea is
that you need to plan well ahead and design everything in a relatively detailed manner before you start to code. And if you’re good at doing the design, the resemblance between what you do and what the customer needs will be sufficient to get you through to the first release without major problems. But along the way, you will probably have yielded to the temptation to make some changes that weren’t planned, but make the software more palatable to the users. The fact is that user requirements
change, and this tends to corrupt pretty designs. As programming guru Martin Fowler
puts it: "Over time the code will be modified, and the integrity of the system, its structure according to that design, slowly fades. The code slowly sinks from engineering to hacking.""

Also page 38,
"The way that agile methodologies such as Extreme Programming (XP) attempt to solve this problem is by doing less up-front design, making sure it is always possible to
make design changes, and constantly improving the structure of the code using a set
of systematic procedures known as refactoring."

I think it points out the problems existing in many companies. At the beginning, the whole team is very ambitious and positive that they believe they can produce an elegant, robust and efficient system/application. They do excellent job at design. However, most of the applications end up as a buggy, ugly and unreasonable monster. The problem is, requirement keeps changing and new features keeps being added. You can't foresee all the requirements at design phase. This particularly applies to web application development.