Writing code, which is easy to change is the Holy Grail of programming. Welcome to programming nirvana! But things are much more difficult in reality: source code is difficult to understand, dependencies point in countless directions, coupling is annoying, and you soon feel the heat of programming hell. In this tutorial, we will discuss a few principles, techniques and ideas that will help you write code that is easy to change.

He covers some of the good OOP principles to think about when developing - like cohesion, orthogonality and coupling (via class methods, polymorphism, dependency injection or interfaces). He spends some time looking at the SOLID development principles and how you can implement each of them in some sample code. He also talks some about high level design and how the separation of concerns can help make your code easier to maintain and change.

Of course you develop using the latest technologies and frameworks. You've written 2.5 frameworks yourself, your code is PSR-2 compliant, fully unit-tested, has an accompanying PHPMD and PHPCS config, and may even ship with proper documentation (really, that exists!). When a new version of your favorite framework is released, you've already used it in your own toy project and submitted a couple of bug reports, maybe even accompanied with a unit test to prove the bug and a patch that fixes it. If that describes you, or at least the developer you want to be: reconsider the relationship your code has with the framework.

He talks some about the dependencies most code written today has on the frameworks it lives in and how a good project design can make it easier to decouple this relationship. He suggests using things like wrapper classes (think "services") to abstract out the functionality to custom components. It's these components that handle the work, just reporting back the results to the controller/model that called them.

The advantage of this is that you can easily implement different methods to persist objects without having to rewrite parts of your code. I'm again going to use the programming language quiz game I wrote as an example. Since I initially wrote it to use Doctrine ORM directly, and both the old and new code are available, you can easily see how the code was improved.

He starts off with a look at the pattern itself (including a diagram of how an example would work with Doctrine) followed by the creation of the models for his Questions example. Add in the factory to create an instance and an exmaple of it in action and you're there.

In the course of this second tutorial, I'm going to show you how to create a bridge class which will come in handy for decoupling the validation of user-supplied data. There will be a class that defines generically how certain data must be verified, while others will implement different validation methods.

They start with building a simple bridge class, a validator class that defines methods to check strings, numbers, alphabetic, and email values. For each of these types, they create the corresponding bridge class that validates the input. Finally, they tie it all together, validating an example of each, handled inside of try/catch blocks to watch for the errors that might be thrown.