Refactoring Applications

---

The problems we've seen in our discussion forum highlight the types of problems that often tend to appear in applications. Fortunately all is not lost, even if the application contains such problems: we can attempt to refactor the application. Refactoring basically means changing from one form to another, and although not strictly "design", it does promote some of the same thought processes. When we refactor a piece of software, it generally means that we change the internal structure in some way without damaging the functionality that it provides.

Refactoring is something that we probably all do already without realising. Some of the reasons why we might want to refactor a particular piece of software might include to tidy it up, to fix bugs, or to simply extend it. The downside to all of this is that refactoring can be a very time-consuming process.

If we had taken a step back before we ploughed straight into coding our discussion forum, we could have foreseen that we needed authentication on many pages and designed a flexible, standard way of performing this task. As it stands, we've had to copy the same piece of code into several different pages in our application, therefore reducing the maintainability and increasing the likelihood that somebody might breach our system.

We highlighted many of these issues when we discussed the Model 1 architecture near the start of the chapter. Lack of extensibility is one of the key downsides to web applications built upon the Model 1 architecture - there is no centralized place for business logic and it is generally embedded into the view components such as JSPs. This makes extensibility difficult to achieve, which in turn makes it hard to keep up with the ever-changing requirements of businesses in the internet world. This isn't to say that applications built using a Model 1 architecture don't have their place - small sites, prototypes and proofs of concepts are well-suited to this. It's just that most large-scale web sites need a more maintainable and extensible solution.

With this in mind (and instead of refactoring the entire system), let's look at how we can use Model 2 architecture and a handful of J2EE patterns to design and build a more maintainable, extensible and secure version of our discussion forum.

---