Friday, November 21, 2008

Some thoughts about reading Patterns of Enterprise Application Architecture

First of all, it is a good book. There is no doubt for that. Its author name, Martin Fowler, is a guarantee in quality.

However, I think it might be better if we read it from its Part 2: The Patterns. And then refer back to Part 1: The Narratives. The reason is simple, if you don't have any knowledge of those patterns, reading part 1 doesn't help you a lot and would not offer you any valuable information. If we start from Part 2 and get a solid knowledge of the patterns and their implementation, we can easily link them with our practice. And it may be just like, ah ha, that is it! And then if we turn back to part 1, we can get our knowledge solid.

It is just my personal thought about reading this book.

Refactoring:Introduce parameter object

This is refactoring is to reduce the long parameter list. Long parameter list make it hard to understand and maintain. It bring down the code's readability either. Introduce a parameter object is a natural solution to this problem. Parameter object contains numbers of get methods to get the parameter value used in other methods.

However, compared with other program languages, PHP contains the most powerful and flexible array functionality. PHP developers are temped to use array to group all necessary parameters. The good side of using array lies in simplicity. However, the downside is obvious as well. You can't guarantee array's integrity, and you need to check if a parameter is contained in an array everywhere in functions that accept this array as parameter.

Wednesday, November 19, 2008

Refactoring:Compose Method

Today I applied this refactoring to extreme. Let's learn some theory about it after lots of practice. Below are all quoted from Refactoring to Patterns.

"You can't rapidly understand a method's logic.

Transform the logic into a small number of intention-revealing steps at the same level of detail. "

"A Composed Method is a small, simple method that you can understand in seconds. Do you write a lot of Composed Methods? I like to think I do, but I often find that I don't, at first. So I have to go back and refactor to this pattern. When my code has many Composed Methods, it tends to be easy to use, read, and extend."

For people who worry about performance issue, the book also clarify:

"Once you finish this refactoring, you will likely have numerous small, private methods that are called by your Composed Method. Some may consider such small methods to be a performance problem. They are only a performance problem when a profiler says they are. I rarely find that my worst performance problems relate to Composed Methods; they almost always relate to other coding problems."

Benefits and Liabilities
+ Efficiently communicates what a method does and how it does what it does.
+ Simplifies a method by breaking it up into well-named chunks of behavior at the same level of detail.
– Can lead to an overabundance of small methods.
– Can make debugging difficult because logic is spread out across many small methods.

I think this is a technique we need to use in most of refactorings. Because a typical procedure program/code is usually hard to understand especially when the procedure is horribly long and contains lots of conditional logic.

Sunday, November 16, 2008

Refactor Conditional Logic

In the book Refactoring to Patterns:
"Martin Fowler writes, "One of the most common areas of complexity in a program lies in complex conditional logic". We often find such logic in algorithms because they tend to grow, becoming more sophisticated over time. "

Conditional logic contain two kinds of statement: if...else... and

The book Refactoring presents us below refactoring techniques:

Replace Type Code with Class
Replace Type Code with Subclasses
Replace Type Code with State/Strategy

Decompose Conditional
Consolidate Conditional Expression
Consolidate Duplicate Conditional Fragments
Remove Control Flag
Replace Nested Conditional with Guard Clauses
Replace Conditional with Polymorphism
Introduce Null Object
Introduce Assertion

The book Refactoring to Patterns also demonstrate below conditional logic related refactorings:

Replace Conditional Logic with Strategy
Replace Conditional Dispatcher with Command
Move Accumulation to Visitor
Move Embellishment to Decorator
Replace State-Altering Conditionals with State
Introduce Null Object

As conditional logic is a common issue that increase a program's complexity and reduce its readability, examine these refactoring techniques become instructive.

Thursday, November 13, 2008

Refactoring: Replace Conditional Dispatcher with Command

Quote from the book Refactoring to Patterns:

Conditional logic is used to dispatch requests and execute actions.

Create a Command for each action. Store the Commands in a collection and replace the conditional logic with code to fetch and execute Commands.

The main idea is to create a command for each action, and then create a sort of command lookup class to lookup the request and delegate to the command.

This can work very well if you can easily decide what command should be taken from the request. Actually, in PHP web development, command pattern might be the most common pattern.

However, things become a little hard if you cannot easily find out the corresponding command to the request. In this situation, I would think of chain of command. Let each command decide if it should process the request by itself. If it should, it will process it and stop, otherwise, the request will be passed to the next command and so on.

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.

Monday, November 10, 2008

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.