First, I think it helps to see an example to more fully understand the differences between logical and physical design, the importance of giving equal consideration to each, and the impact that each have on the flexibility of your software. This should help you understand the problem we're faced with when developing large software systems where we want to obtain a decent degree of reuse, maintainability, and extensibility.

Second, it should make the subsequent discussion on each of the heuristics much clearer by providing a context to which the heuristics can reference. Therefore, throughout the discussion in this chapter, I have planted references to many of the heuristics, allowing you to refer to a more detailed discussion should you have that desire.

I like to pick examples that are easy to follow, yet provide a bit of substance. The following example uses a payment calculator, similar to one you might use in popular spreadsheet programs to calculate the monthly payment for a loan. There are three versions, and the advantages and disadvantages of each are discussed.

Notable highlights of this discussion will include DependencyInjection and the use of LightweightContainers.

• Version 1 of the component contains all concrete classes. It calculates the average monthly payment and a payment schedule.
  • Advantage - Easy to understand and use.
  • Disadvantage - Inflexible and doesn't accommodate change well.
• Version 2 provides some abstractions that help configure the loan with the option to specify a desired monthly payment. The desired monthly payment must be equal to or greater than the minimum monthly payment calculated based on the term of the loan.
  • Advantage - Ability to create separate calculators for a payment schedule based on the minimum monthly payment and a payment schedule based on a desired monthly payment.
  • Disadvantage - Slight increase in complexity. Certain areas still don't accommodate change well.
• Version 3 assumes we'd like to replace our loan payment calculator with a vendor package. Ideally, when we do this, we want to reduce the ripple effect of making this change. To accommodate this need, classes using the component must depend only upon abstact elements. To accomplish this, we have separated the interface and implementation into separate components. The implementation for Version 3 are adapter classes that serve as a facade to the vendor packages. Version 3 builds on Version 2 and shows how the complete separation of interface and implementation is a very flexible design mechanism. This sample also shows how a URLClassLoader? can be used to load the implementation from a remote source. This could just as easily be implemented as a web service. A very cool and real possibility. To start with, Version 3 is just a facade to Version 2.
  • Advantage - Very flexible. Allows us to switch the entire implementation of loan calculation with another component without impacting client code.
  • Disadvantage - Complexity.

Soon, I'll be posting the sample code to this page.