Categorizing Patterns

The process of categorizing patterns is very subjective , to say the least. Ask two different object-oriented enthusiasts , and surely you will receive two different means of identifying patterns. This is not to say that the GoF categorization process cannot be applied. In fact, it is rather effective once you understand the patterns. The trouble is when you are just getting your feet wet with this type of material, the categories don't strike as much familiarity as they could to aid in their understanding. After all, one of the reasons for categorizing and cataloging them is to aid not only in their referencing but in their learning. You do not have to truly understand any pattern category to understand the pattern itself. You can succeed nicely by simply "thumbing" through the library of patterns and trying each one on to see whether it would benefit. However, it would still be nice for those just approaching the topic to be able immediately to recognize the category description, even if they haven't worked with patterns in the past. Besides aiding those who have read the material and may need to look up a pattern for a solution, a category should also help the discovery process. This is especially true if reading the material for the first time.

In this book, I first attempt a more familiar categorization scheme by leveraging a little of what all developers have most undoubtedly already experienced . These experiences include providing a software design, architecture, and ultimately implementation, even if it was not object oriented. This can be any design or any architecture. The point is that you should be familiar with this term and already have a concept of what makes up a design element and what makes up an architecture element. Surprisingly enough, some do not understand the difference. Part of that reason is that they tend to overlap a bit in meaning with one another. However, the act of design and the act of architecture are different, indeed. Just ask any object-oriented designer working on a detailed class diagram for a particular business service. This activity may take into account the architecture but it itself is not an architecture element. You can also approach an architect with this same question.

A sound design does not necessarily mean a sound architecture and vice versa. I know of many "sound" designs that took into account every object-oriented best practice and still suffered, due to having a poor architecture. To simplify the meaning of the differences, you can simply remember that architecture tends to closely align with technology, tools, and environmental elements and is not necessarily aligned with object-oriented concepts. On the flip side, designs should be abstracted as much as possible from these same alignments, although considerations always need to be made. Nothing is truly static, after all.

Challenge 1.6

What are some example of patterns that can be both middle- tier and/or presentation-tier patterns?

The answer appears in Chapter 3 ”the first example of such a pattern lies on page 108

I also leverage off of any "common" developer experiences based on the fact that most of you have already built some form of three-tier or N-tier system in your career. This book first gives each pattern a "type" classification to mimic the types of work a developer performs . The types are implementation, design, and architecture. This book also uses well- understood principles of N-tier systems by using this other form to help classify the patterns. These broad classifications are presentation tier, middle tier, and persistence tier. These are just fancy names for user , business, and data layers or services. In fact, even these categories are rather "fungible." Patterns that are one type and one category can be easily interpreted as belonging to another type and category. So hopefully, this won't cause any heated debates over what is considered an architecture pattern at the middle tier versus one that resides on the persistence tier. What this system hopes to do is help you answer the following questions:

• How much of the pattern is abstracted from technology?

• How applicable is the pattern for a particular implementation?

• At what level is this pattern implemented?

• Is the pattern repeatable using different implementations ?

• At what granularity is the pattern applied?

• Is the pattern related to a known pattern, such as a GoF pattern, and at what level?