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

Both of these books heavily refer to some typical software development books: Design Patterns (Gang of Four), Refactoring (Martin Fowler), patterns of enterprise architecture (Martin Fowler), etc. Basically, these two books are trying to introduce concepts like design pattern, architecture, refactoring, which are common to java developers, to PHP. So, if you find these two books helpful, it is natural that the next step should be those reference books.

Both books introduce some common design patterns which may be used frequently in PHP development, for example, Factory, Singleton, Strategy, Observer, Composite, Command, Decorator.

However, I think both of them missed another important pattern: Delegate.

There are some other design patterns, which, based on my experience, are not often used in PHP development, are introduced in the two books. PHP In Action shows us Adapter, and the other book explain Interpreter.

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.