Design Patterns Explained: what it's about

[Alan Shalloway]

The difference between virtually all design pattern books and ours: Design Patterns Explained: A New Perspective on Object-Oriented Design, is that our book is more about why design patterns are good designs. The intent is so you understand what good design is and can then do that whether patterns are present or not. Essentially, we teach design patterns in a way that the reader gains an understanding of the principles and rationale for the patterns, what is driving them, and how to use them. We also use the patterns to teach the reader what object-orientation is really all about ("why you care about inheritance" rather than "here is inheritance, now go use it..."). At the end, the reader is equipped to use the more in-depth design patterns books.
The problem with learning patterns is that there are so many out there that it is unlikely you will really know the ones you need. What you need to learn are what are the important things to look for. Patterns teach us this. By learning a few patterns that teach us how to identify and classify what is important in one problem domain we learn how to extend this ability to other domains, even when we arent' sure what the patterns are.
The book is intended to be at an introductory to intermediate level. Definitely an introduction to patterns, but it might surprise some old-timers with some new concepts on OO. I say this because when I started learning design patterns, I was already an experienced OO person. After I truly understood design patterns, my view of OO had changed (hence the sub-title of our book).
------------------
Alan Shalloway,
Look for Jim Trott and my book: Design Patterns Explained
Visit our site Net Objectives www.netobjectives.com

------------------
Alan Shalloway,
Look for Jim Trott and my book: Design Patterns Explained
Visit our site Net Objectives.

[Alan Shalloway]

I've posted three chapters from our book.
Chapter 1: The Object-Oriented Paradigm
Chapter 5: An Introduction to Design Patterns
Chapter 9: The Bridge Pattern
To see them, go to our book's home-page at: http://www.netobjectives.com/dpexplained/dpe_book.htm
Then take: Info which shows the table of contents. Click on the chapter of interest.
Hope you enjoy.
------------------
Alan Shalloway,
Look for Jim Trott and my book: Design Patterns Explained
Visit our site Net Objectives.
Visit our on-line companion to the book

[Ritu Kama]

I have some experience in OO Concepts and Designing and I was sincerely looking for a good book. IF you have a good book, you become more methodical and have a better understanding of the overall picture.
I guess your book is quite talked about here.
Ritu

[LAXMI VEMARAJU]

Alan Shalloway,
I am feeling this subject very confusing. I couldn't find the differences between the patterns. Could you explain me on what basis the design patterns are devided to CREATIONAL,BEHAVIOURAL AND STRUCTURAL? Any hint......on how to remember them?
Thanks,
Laxmi

[Alan Shalloway]

Actually, I don't like these terms. They originate due to how Gamma, Helm, Johnson and Vlissides first looked at patterns. They were looking at patterns from the design point (hence the name). However, Christopher Alexander never thinks of them that way. Alexander is the architect whose idea of patterns in architecture inspired the Gang of Four (Gamma, Helm, Johnson, Vlissides) to look for patterns in software. Anyway, Creational patterns are about creating things - hence the factories go in here. Behavioral patterns are about containing variations in behavior - hence the strategy, state and visitor pattner here. Structural patterns are about bringing things together. It is easy to see why adapter, facade and proxy belong here. In these patterns, things exist prior to the pattern and we use the pattern to have them work together. However, the bridge and decorator also look like they are about containing behavior, so why are they called a structural pattern? The reason is because, again, in these patterns, you typically have implementations that exist for the bridge, or your decorations for the decorator pattern.
However, I don't like these terms because in reality, most patterns have some combination of two or more of these things. Additionally, I like to think of patterns like Observer, Mediator and Chain of Responsibility as being patterns that decouple things -- allowing me to scale. Hence, patterns actually have different degrees of:
1) creating objects
2) containing variation
3) getting existing pieces to work together
4) decoupling or setting up layers between objects
Classifying things into these categories is useful to understand these actions, but isn't really helpful to say: this pattern is of that type.

------------------
Alan Shalloway,
Look for Jim Trott and my book: Design Patterns Explained
Visit our site Net Objectives.
Visit our on-line companion to the book

[Ritu Kama]

Hello Alan,
I tried to view the chapters posted on the site, but I get an error "File is damaged and cannot be repaired".
Thanks anyway
Ritu

[Alan Shalloway]

Ritu:
THanks for letting me know. It should work now (although you will probably have to hit the refresh key).
------------------
Alan Shalloway,
Look for Jim Trott and my book: Design Patterns Explained
Visit our site Net Objectives.
Visit our on-line companion to the book

[LAXMI VEMARAJU]

Thanks for the reply Alan.
I am able to open the link as well as the .pdf files, I didn't faced any problem.
Laxmi

[Paul Stevens]

Alan,
This was your reply on a different thread but is more applicable here:
Gang of Four's Design Patterns: Elements of Reusable Object-Oriented Design - still the best book on patterns (or at least the best once you know what they are).
So how do you go about knowing what they are? We have that book here at work and I recently started looking at it. So far it has been dry reading. Should you just skim and know the names and what they do then get further in depth or what.

[Alan Shalloway]

Originally posted by Paul Stevens:
Gang of Four's Design Patterns: Elements of Reusable Object-Oriented Design - still the best book on patterns (or at least the best once you know what they are).
So how do you go about knowing what they are? We have that book here at work and I recently started looking at it. So far it has been dry reading. Should you just skim and know the names and what they do then get further in depth or what.[/B]

********
I believe the Gang of Four book is still the best book on learning about particular patterns. Although the examples are written in C++ and smalltalk, their discussion of forces is the clearest and most extensive for the patterns they cover. Grand's book is not too bad a reference to get java examples.
As far as learning patterns, I suggest you learn 3-4 patterns in detail, particularly: strategy, bridge, abstract factory, composite. These are used all over the place. Then, go through the Gang of Four book just reading enough of each chapter to understand where the pattern applies. It only takes a few hours to do this (you're only reading a few pages of each chapter). Then, twice a day for a couple of weeks, try to remember the pattern names and what they are for (about 5 minutes each time is all it takes). Write down the ones you remember, look in the GoF book for the missing ones. After a couple of weeks (10 minutes a day of work) you'll know at least what all of the GoF patterns are, even if you can't implement them (you'll know when they are needed). Then, when you need one, learn it.

------------------
Alan Shalloway,
Look for Jim Trott and my book: Design Patterns Explained
Visit our site Net Objectives.
Visit our on-line companion to the book

[Paul Stevens]

Thanks Alan.

[Ian Lockwood]

Allan, I am a final year IT degree student in the UK. I have a year of Java experience and some basic knowledge of OO in general. I have heard about design patterns and even begun to look at some books on the subject but they seemed way to complicated for me. Is your book really diferent? Is it going to help me learn what patterns are as well as how to use them? My final year project which I am just begining is going to be designed and written in an OO way and I am looking for some good refernece material at the design stage will your book he;p me in this?
Thanks Ian

[Alan Shalloway]

Originally posted by Ian Lockwood:
[B] Is it going to help me learn what patterns are as well as how to use them?
Ian:
You are almost exactly the person we wrote the book for. Try reading the first chapter (on-line at our site at: http://www.netobjectives.com/dpexplained/dpe_info.htm) If you to try a more complex chapter, read chapter 9 (the bridge pattern). If you have troubles understanding it, use our discussion group on our site at www.netobjectives.com/dpexplained (take discussion group) and we'll answer questions posted about the book there. Of course, this week, most of the activity is going to be here. Boy, Javaranch people ask a lot of questions
------------------
Alan Shalloway,
Look for Jim Trott and my book: Design Patterns Explained
Visit our site Net Objectives.
Visit our on-line companion to the book

[Paul Jenkins]

Alan,
Care to comment on the over-use of OO and patterns in highly scaleable systems? I very often see people attempt to apply OO to every solution, and in most highly scaleable solutions, 'traditional' OO doesn't work. Do you address this in your book/writings?
Thanks,
Paul

[Alan Shalloway]

Originally posted by Paul Jenkins:
Alan,
Care to comment on the over-use of OO and patterns in highly scaleable systems? I very often see people attempt to apply OO to every solution, and in most highly scaleable solutions, 'traditional' OO doesn't work. Do you address this in your book/writings?
Thanks,
Paul

I would agree that traditional OO doesn't work very well. Of course, I don't think it works well even for medium size applications. That's what our "new perspective" is about. It's what the Gang of Four means when they say:
1) design to interfaces
2) encapsulate what varies
3) favor composition over inheritance.
OO is definitely mis-used, but I think that is distinct from overuse. What is OO anyway? I think it is making a distinction between what we want something to do at a conceptual level and how it does it at an implementational level. OO gives us the tools to define what objects will do (their interfaces) distinct from how they do it (their implementations). Design patterns are just designs for this. OO learned from Design patterns teaches us to push responsibilities down as low as possible so the using objects don't need to know the details. This allows for the details to change without affecting our interactions.
Design patterns teach us to make abstractions based on variations in isness and behavior (not just inheritance hierarchies). Using commonality/variability analysis to define our objects is much better than using nouns. However, i never would have seen this without having seen how many patterns work.


------------------
Alan Shalloway,
Look for Jim Trott and my book: Design Patterns Explained
Visit our site Net Objectives.
Visit our on-line companion to the book

[Paul Jenkins]

Alan,
Good points. What I mean by 'overuse' is that everything is an object, that objects overuse interfaces and calls to other objects, that too many objects exists and too many layers of abstraction are present, etc., etc. Things you are probably well aware of. Patterns are a great concept and are a great thing to have in one's toolbox to utilize. However, they often times do not address the core problems in systems, that of building scaleable, reliable, easy-to-maintain and debug systems that do not hide behind the overuse of objects. The simplest example is the object that uses another object by calling 5 methods to accomplish one atomic task. 5 times the overhead and complexity for the same result. Multiple that out by the number of objects in a system, the number of interactions between them, the amount of non-local access and resources that are consumed by the objects, such as database connections, stored procedure or sql calls, cross-process communications, etc., and I think you get my drift.
That is what I'm asking if your book addresses. Rehashing traditional OO patterns into Java isn't much of an advance, I'm hoping you tackle the harder issues which people tend to ignore and which, sorely, needs more addressing in the development world...
Thanks,
Paul

[Alan Shalloway]

Originally posted by Paul Jenkins:
The simplest example is the object that uses another object by calling 5 methods to accomplish one atomic task

Paul:
How would you get to this point? What would someone have to have been looking at to do this? Certainly not motivations lying in the problem domain. I think many problems come from people looking at things from the wrong perspective. In the book we look at the motivations behind the patterns. I do not believe this type of abuse happens when you do that.

------------------
Alan Shalloway,
Look for Jim Trott and my book: Design Patterns Explained
Visit our site Net Objectives.
Visit our on-line companion to the book

[Paul Jenkins]

Originally posted by Alan Shalloway:
Paul:
How would you get to this point? What would someone have to have been looking at to do this? Certainly not motivations lying in the problem domain. I think many problems come from people looking at things from the wrong perspective. In the book we look at the motivations behind the patterns. I do not believe this type of abuse happens when you do that.

I've been a project manager/CTO for over 5 years now and I haven't had a team yet that hasn't done this. They attack the problem from the philosophy of "get it working", then "get it fast" and that performance/stability/reliability are things that can be done "after it works". I've been fighting against this mindset, and hope to find other works that help in training people on proper system design and implementations. They are hard working, well meaning people, but they do, many times, attack problems from the wrong vantage point, without thinking through the ramifications of what they are doing. That is one reason why XP is so frought with peril, imho. You have, to many people, an excuse to just hack even more than they do today, the results, systems that don't scale, don't perform and are riddled with bugs...
sorry to get off on a bit of a tangent, just a sore point with me hopefully your book helps in this area.
paul

[Alan Shalloway]

Paul:
Sorry, I wasn't clear. You're right - most people do get to the point you described. I didn't mean to imply they didn't. What I meant was, what were they looking at (or not looking at) that got them there. You mentioned some of the things - let's get it working then we'll get it working right. This attitude implies getting it working without doing it right is somehow faster. I believe when you understand the principles behind things you can move faster doing it right in the first place. Principles like loose coupling, high cohesion can guide coding quite well. I also think XP is fraught with dangers. I love the principles underneath it, but think it too simplified. The coding guidelines about "simplest is best" do not actually work without a solid understanding of what simplest means (which are inaccurately described in the XP books, in my opinion).
Our book attempts to get you to think about what you are doing and which principles work, why they work and when they work.
------------------
Alan Shalloway,
Look for Jim Trott and my book: Design Patterns Explained
Visit our site Net Objectives.
Visit our on-line companion to the book

[Iyengar Srividya76]

Hi Alan Shalloway,
I don't have any experience in 'Design Patterns' but I ofcourse manage to understand the OO concepts.... But the topic 'Design Patterns' seems to be a bit complicated.... I had initially started reading the book by Erich Gamma.... found it a bit dry and also not for beginners.... so downloaded the pdf of Cooper.... it seems ok...
not very clear with the concepts....
What's the actual difference between Creational, Structural and Behavourial Patterns.... Need some real life examples and then some examples on Objects and classes... so that mapping becomes easier and the topics seems interesting....
Also can u pls explain me 'Abstract Factory', Adapter pattern and the diff between Object adapter and class adapter....
Again I have downloaded the chapters 1,5,9 from the site seems to be really good....
Thanx...
Vidya

[Alan Shalloway]

Originally posted by Iyengar Srividya76:
Hi Alan Shalloway,
Also can u pls explain me 'Abstract Factory', Adapter pattern and the diff between Object adapter and class adapter....
Again I have downloaded the chapters 1,5,9 from the site seems to be really good....
Thanx...
Vidya

Glad you are enjoying the chapters.
See the post dated: posted October 02, 2001 10:16 AM
under Design Patterns Explained: What it's about for an explanation of the terms Creational, Behavioral, Structural
Abstract factory is when you need to create a family of objects. The family is related because of the case you are workin on. For example, let's say you were to be writing an e-commerce system that needed to handle tax, freight charges, and address rules for different countries. You could define interfaces for each of these types of objects and then have different implementations for each country needed. However, coordinating which objects to instantiate can be problematic.
The abstract factory tells us to make an object that has a method to create each type of object needed. The abstract factory can be implemented in many ways, but now the main program just asks the abstract factory object to create the set of objects needed. I have a very good and fairly detailed example of this in the book (not one of the 3 chapters, however).
The adapter (or wrapper) is when you have the correct functionality, but the wrong interface. Adapter is used more and more the more you use design patterns. The reason for this is that you will find that design patterns teach you to design to interfaces. This is done using interfaces and abstract classes. If you have functionality, but it has the wrong interface, then you'll need to adapt it (i.e., change its interface to what you want). Object adapter is accomplished by creating an object with the correct interface and containing the one the does the function. Each of these wrapping methods simply calls the adapted object. The class adapter uses multiple inheritance to make a new class that derives both from the abstract class that has the interface we want and the object that does the work. This clearly works in C++, but not in Java (remember the Design patterns book pre-dates Java).
Thanks for your questions.
------------------
Alan Shalloway,
Look for Jim Trott and my book: Design Patterns Explained
Visit our site Net Objectives.
Visit our on-line companion to the book

[Ruby V]

Alan,
How is the adapter pattern different from a decorator pattern? Both seems to be a wrapper. Could you explain this in terms of java ( I don't know C++).
Thanks.
Ruby

[Alan Shalloway]

Originally posted by Ruby V:
Alan,
How is the adapter pattern different from a decorator pattern? Both seems to be a wrapper. Could you explain this in terms of java ( I don't know C++).
Thanks.
Ruby

They are both wrappers of a type. However, again, motivations are different and structures are considerably different. In the adapter, you've got one thing that needs its interface changed.
In the decorator, you have a function you want to add to dynamically. By dynamically, I mean one time you run the program you may want to have one set of added functions and another time you may want a different set. Java IO uses the decorator (probably overkill), but it illustrates the point. Say you want to do stream IO. Sometimes you want to encrypt it and zip it. Sometimes you want to do CRC checking. However, the user doesn't want to worry about these details. Decorator builds a chain of decorators ending with the original function. So in adapter, we have the same function with a different interface. In the decorator we have different functions (albeit, always with our original/main function being done) with the same interface.

------------------
Alan Shalloway,
Look for Jim Trott and my book: Design Patterns Explained
Visit our site Net Objectives.
Visit our on-line companion to the book

[Ruby V]

Alan,
Suppose, I create a List in different ways in various classes, example :
1) List a = new ArrayList(); inside class A
2) List a = new Vector(); inside class B
And then call the same List(interface) in main method.
Then, would you call the above an Adapter pattern?

[Alan Shalloway]

Originally posted by Ruby V:
Alan,
Suppose, I create a List in different ways in various classes, example :
1) List a = new ArrayList(); inside class A
2) List a = new Vector(); inside class B
And then call the same List(interface) in main method.
Then, would you call the above an Adapter pattern?

This is not adapting, this is polymorphism. You are referring to ArrayLists and Vectors as if they are lists, because they are types of lists. You are treating different objects the same because they support the same interfaces, they have been originally designed this way. Now, let's say you had a collection that was _not_ a List, but you wanted to treat is as one. Let's call this MyCol. You can't do List a= new MyCol because MyCol is not a list. However, you could make a new implementation of List called AMyCol that wraps MyCol. Then, you can do List a= new AMyCol, affectively using MyCol as a list. Of course, if you were writing both of these, you'd probably just write MyCol to support the interface you wanted in the first place and not need to adapt. The adpater is used when you already have the class and now you see that you need a different interface.

------------------
Alan Shalloway,
Look for Jim Trott and my book: Design Patterns Explained
Visit our site Net Objectives.
Visit our on-line companion to the book

[Ritu Kama]

I am quite interested in reading this book that is so talked about. Specially after so many people have mentioned different startegies and patterns.
a)Does your book list case studies and their possible design implementation? This would be a great help for us beginners.
b) Does your book list a step by step approach in building a design? Normally we go through series of cycles and revisions to finalise on the design of a system
Thanks
Ritu

[Ruby V]

Thank you for your clarification. Could you also give me an example of a decorator pattern or show how it is used in javaIO?

[Alan Shalloway]

Originally posted by Ruby V:
Thank you for your clarification. Could you also give me an example of a decorator pattern or show how it is used in javaIO?

The best place to find an example would be to go to http://www.mindview.net/ and look for Bruce Eckel's Thinking in Java book (it's online). Scan for Decorator. He's the one who gave me this insight.

------------------
Alan Shalloway,
Look for Jim Trott and my book: Design Patterns Explained
Visit our site Net Objectives.
Visit our on-line companion to the book

[Alan Shalloway]

Originally posted by ritukama:
I am quite interested in reading this book that is so talked about. Specially after so many people have mentioned different startegies and patterns.
a)Does your book list case studies and their possible design implementation? This would be a great help for us beginners.
b) Does your book list a step by step approach in building a design? Normally we go through series of cycles and revisions to finalise on the design of a system
Thanks
Ritu

This question has been asked a couple of times in a slightly different way. I know it's really difficult to see everything that is going on the site, so I'm starting to make a set of FAQs on my books community page. Check out my answer at: http://www.netobjectives.com/dpexplained/dpe_olc_faq.htm

------------------
Alan Shalloway,
Look for Jim Trott and my book: Design Patterns Explained
Visit our site Net Objectives.
Visit our on-line companion to the book

[Ritu Kama]

Hi Alan,
That is really a great idea to put up an FAQ page. I checked the page out.
Thanks for quick reply.
Ritu

[Ruby V]

Alan,
I had a look at the "Thinking in Java " site. but am a little confused about the decorator pattern by looking at the structure of the packaging Maybe I need to read a couple of times more to be able to recognise the design clearly.
One more question, which design pattern are the following wrapper classes based on......WrappedPlainView,Integer,Double etc.
Thnaks.
Ruby

[Alan Shalloway]

Originally posted by Ruby V:
Alan,
I had a look at the "Thinking in Java " site. but am a little confused about the decorator pattern by looking at the structure of the packaging Maybe I need to read a couple of times more to be able to recognise the design clearly.
One more question, which design pattern are the following wrapper classes based on......WrappedPlainView,Integer,Double etc.
Thnaks.
Ruby

Not everything is based on a design pattern and I'm not sure I'd call these based on one. In a sense, you could call them adapters, however, because they all derive from Object thereby allowing us to treat them all the same.

------------------
Alan Shalloway,
Look for Jim Trott and my book: Design Patterns Explained
Visit our site Net Objectives.
Visit our on-line companion to the book

[LAXMI VEMARAJU]

Alan,
What is MarkerInterface? In the book they gave Snapshot as the related pattern, but I couldn't understand it.Could you make me clear?
Laxmi

[Iyengar Srividya76]

Thanx Alan for the explanation.
I have read about 'Adapter Pattern' in Cooper's material. He has used an example on List and JList to explain the 'Adapter Pattern' and the diff btw 'Object Adapter'and 'Class Adapter'. But still not clear. Can u give me a diff example.
Would really appreciate if u can give some example on this.
Thanx again,
Vidya