Before we get into how to use design patterns, objects, and OO-design, it's worth discussing why we should be "designing" our PHP applications in the first place. PHP is a simple scripting language, some people say - you shouldn't ever need objects; functions and simple pages will do.

For a lot of things, they certainly do. But there are a number of situations where you may want a higher level of organization:

• Code intended to be used by others
• Code being developed by a large development team
• Code that you will have to maintain

Code intended for use by others: Any class libraries, applications that you want to distribute and expect others to modify, or similar code automatically have a higher standard of readability, documentation, and organization than the couple of scripts that you threw together to make your website a bit snazzier.

Code being developed by a large team: Large development teams often are exactly analogous to the too many cooks, spoiling the broth. The only way to avoid constantly rewriting everyone's work is to have a plan and stick to it, and that means having a coherent design thought out from the outset. Will things still change, and will you likely forget something anyway? Yes. But you'll still save a huge amount of time and pain. "If you plan on having to rewrite your application once, you'll end up rewriting it twice. Plan on getting it right the first time, and you'll only rewrite it once."

Code you have to maintain: This is your own skin, and sometimes it's necessary to get something out the door so quickly that you know it will come back to bite you later - I'm sure management has put all of us in that position. But if you have a choice in the matter, leaving yourself well-organized code will provide many more cues to your memory on how everything works.