I have a lot of experience building web applications that separate business logic from presentation and have been using Zend Framework’s model–view–controller (MVC) components for over two years now. This has certainly helped make web applications I work on more maintainable. However, creating effective models (the “M” in “MVC”) has always been difficult (this has nothing to do with Zend Framework and has everything to do with the difficulty of modeling in general). The Zend Framework team has been relatively quiet on models since modeling tends to be specific to your application’s domain (although Matthew Weier O’Phinney recently gave a great webcast and presentation on modeling in Zend Framework).

The Domain-Driven Design book has helped make a lot of things “click” for me. It drives home the point that modeling is a domain-specific task and that the complexity is usually in the domain, not the technical aspects of your project. If you think the complexity is in the technology then you should question your choice of tools (in my opinion) but in this case perhaps domain-driven design isn’t right for you. The book provides many patterns that help keep the focus on the domain. Arguably the most important of these patterns is the Ubiquitous Language which is “a language structured around the domain model and used by all team members to connect all the activities of the team with the software.” Other important patterns include Entities, Value Objects, Services, Repositories and Factories.

If effective modeling has been something that you’ve struggled with then I’d urge you to check out Eric Evans’ presentations and then read his Domain-Driven Design book.

Reuse is extremely important but difficult to achieve. You don’t get it for free, but it is achievable.

The lure of object-oriented programming is the ability to reuse code. However, creating reusable code is not as simple as switching from procedural to object-oriented programming. One may make the switch from procedural to object-oriented programming and then be disappointed that object-oriented programming didn’t deliver on the promise of reuse. Josh Bloch has a potential solution to this problem but it requires one to think about software in terms of public APIs.

Being disappointed with object-oriented programming, one may then decide to try agile programming, perhaps even extreme programming. One tenant of extreme programming is to “do the simplest thing that could possible work.” Josh Bloch points out that this is easy to misconstrue:

The extreme programming proponents don’t advocate writing something that will barely work as fast as you can. They don’t advise you to forgo any design. They do advocate leaving out the bells, whistles, and features you don’t need and add them later, if a real need is demonstrated. And that’s incredibly important, because you can always add a feature, but you can never take it out. Once a feature is there, you can’t say, sorry, we screwed up, we want to take it out because other code now depends on it. People will scream. So, when in doubt, leave it out.

He goes on to talk about other topics such as minimizing mutability, protected vs. private members, when to make a class final, and the copy constructor as a cloning mechanism. It is interesting reading if you are striving for the goal of reusable object-oriented code.