This Weeks Giveaway

[Fei Ng]

Does this book use Java or C++ for code examples?

[Dave Van Even]

i'm getting the hang of this.. I read chapter 1, 5 & 9 and I love it...
I've just droped out of school and therefore my parents aren't gonna give me any more money... so I'm gonna have to earn it myself Luckely I had a student job as a programmer at a company and they decided to hire me for a month.. My objective is to get a deeper insight in software design and J2EE during that month, so I can go search for a soft. analyst/programmer job..
So, when I got the money, I'm gonna buy your book
Dave

[Anonymous]

Given a problem and its domain, I would like to know more about the approach to arrive at a particular pattern (or patterns coalescing to provide a solution).
How can this book help me in that endeavor?

------------------
Regards,
Milind.

[ruilin yang]

We know there are many design patterns developed, e.g. listed in the book GoF. I feel it is important to understand the general goal(value)of using these patterns. Can I say the goal of using the patterns to produce software systems:
1) easy to extend
2) promote more code re-use
3) easy to maintain
e.g. loose coupling between functional modules.
In this direction I would like to get more useful comments.
Thanks in advance.
Ruilin

[ruilin yang]

We know there are many design patterns developed, e.g. listed in the book GoF. I feel it is important to understand the general goal(value)of using these patterns. Can I say the goal of using the patterns to produce software systems:
1) easy to extend
2) promote more code re-use
3) easy to maintain
e.g. loose coupling between functional modules.
In this direction I would like to get more useful comments.
Thanks in advance.
Ruilin

[Ricardo Polero]

Hi, all
I want to participate PLEASE

[ZEESHAN AZIZ]

DO YOU THINK THAT COLORS MAKE A BIG DIFFERENCE IN OO , UML DRAWINGS, AND IF THAT IS THE CASE, WHERE CAN WE GET MORE INFORMATION ABOUT IT.
Regards,
Aziz.

[Alan Shalloway]

Originally posted by FEI NG:
Does this book use Java or C++ for code examples?

see FAQ 3 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

[Alan Shalloway]

Originally posted by Milind Prabhu:
Given a problem and its domain, I would like to know more about the approach to arrive at a particular pattern (or patterns coalescing to provide a solution).
How can this book help me in that endeavor?

This book will help you see that it is more important to look for variation in your problem domain than it is to look for entities in your problem domain. It will explain why high cohesion is useful, why loose coupling is useful, why objects should be responsible for themselves. It will also show have several patterns can work together. It won't show you how to find patterns or how to write them up. it will also show why looking at the context of your problem domain is more important than finding your individual classes and then putting them together.

------------------
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 ruilin yang:
We know there are many design patterns developed, e.g. listed in the book GoF. I feel it is important to understand the general goal(value)of using these patterns. Can I say the goal of using the patterns to produce software systems:
1) easy to extend
2) promote more code re-use
3) easy to maintain
e.g. loose coupling between functional modules.
In this direction I would like to get more useful comments.
Thanks in advance.
Ruilin

While patterns have the advantages you mention, I think the real advantages of patterns is that they teach you what good design techniques and principles are. Inheritance is more often misused than used properly. It should not be used to specialize or directly re-use code. It should be used as a way of treating different concrete implementations that are conceptually doing the same thing in the same way. This way the using program doesn't have to worry about these implementation differences. It allows for new implementations to be done without affecting the using program.
This can be accomplished by using inheritance to contain different things that are conceptually the same within an interface or an abstract class.
This type of design shifts your level of thinking to be more conceptual. Patterns then give conceptual thinkers good tools to work with. It also gives more detailed/concrete/sequential thinkers a way to relate concepts to actual examples.

------------------
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 ZEESHAN AZIZ:
DO YOU THINK THAT COLORS MAKE A BIG DIFFERENCE IN OO , UML DRAWINGS, AND IF THAT IS THE CASE, WHERE CAN WE GET MORE INFORMATION ABOUT IT.
Regards,
Aziz.

Peter Coad of Togethersoft, whom I respect quite a lot, thinks so. His book "Java Modeling in Color with UML" discusses this. There are lots of good points to it.
WHen I do a variety of mind-mapping things with 3x5 cards I usually use different colors and find that useful.
------------------
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 Max Tomlinson:
Could the author please explain the difference between a Business Delegate and a Facade? Seems to me they are very similar. BTW this is a question on one of the Sun Java exams (SCWCD).
thanks,
Max Tomlinson

By business delegate I'm assuming you mean the delegation pattern. If not, please give me more information.
In delegation, one object gets a request and actually performs it by passing on the call to another object. That could be said to be true not only for facade, but for adapter and proxy as well. So why are they different patterns?
Motivation in the problem domain.
Let's get some terminology straight. In all cases we have a client object calling some intermediate object that calls the object that actually does the work. Let's call these the client, the intermeidary and the doer. In the delegate pattern, the client is used to dealing with the intermediary, but now a new function is needed. The intermediary uses the doer object since it presumably already exists. Delegation is a way of reusing code through composition.
In the adapter, the client wants the function of the doer, but the doer has the wrong interface. The intermediary object is made to adapt the doer to the correct interface.
In the facade, the client wants the function of the doer, but doesn't need it all. The doer is more complicated than the client wants to deal with (because not all of the function of the doer is being used). A new object, the intermediary, can be made that only has methods that the client needs. It can be tailored for the way the client wants to use it. It can thus be much simpler to use.
In the proxy, the client wants to use the doer's function, but needs some additional function or some preliminary set up done and doesn't want to deal with it. An intermediary, with the same interface as the doer, can be written that does this extra stuff. In the classic proxy, the intermediary sets up the doer so the client merely instantiates the intermediary object (the proxy) and gets an already set up doer. However, it doesn't know all this is happening behind the scenes, of course.

------------------
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 Shan Karawita:
1) How do we apply patterns on logical level class diagram when we decompose it to implimentation level class diagram.
2) If we're going to use EJB's, what is the help we can get from patterns,when we're going to decide which classes should be session beans & which classes should be entity beans.
3) What's the best stage of applying patterns on design.when conceptual model decomposing in to logical phase or logical phase decomposing in to implimentation desing.
4) In the analysis stage of a system , is it necesary of knowing patterns & start the design keeping all the patterns in mind ?

[B]
1) Patterns at the conceptual level help create the context for the specific implementation to be done. For example, in the bridge pattern, the pattern tells us to define the interface of the implementations so that all derivations of our abstraction can be supported by them. When we work out the specifics of these implementations, this interface gives us the context to implement within.
Patterns thus help take us from concept to implementation. However, I do not like using the uml at the implementation level. To do so requires either round trip engineering (extra work in my mind) or duplicate documentation - extra work that is never done. Personally, if I can see what is going on at the conceptual level clearly with the UML, I can see implementation details in the code.
2) Patterns should help you understand how to assign responsibilities better. There are specific patterns for J2EE, but I'm not an expert there.
3)Patterns exist at all levels - from analysis to implementation. My course on design paterns is called: Pattern Oriented Design: Design Patterns from Analysis to Implementation to illustrate this. "Design" patterns is a misnomer in my opinion. The motivations of particular patterns (why you would use them) can be used in analysis because you can see if you have a need for it. For example, if you have collections of things that you need to handle in the same way, you can figure you probably have a composite pattern. Once you get in design, the pattern helps you see the relationships between your classes. Finally, the patterns help you see how to implement these classes within the context of their relationships.
4) It helps if you know more patterns because they give you things to look for. But realistically, how many times are you really going to know all of the patterns in the problem domain? Probably not many. Especially if you are working on new things (patterns by definition are existing ways of solving things). What's important is to understand the design principles upon which patterns are based, the strategies the writers of patterns used. If you understand these, you can write new code that is as good as code that is later identified as patterns.
------------------
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

[Doug Wang]

Hi, all.
I also read all the sample chapters and love it very much.
I am eager to read the chapters on "Thinking in Patterns" and "Handling Variations with Design Patterns". They sound good.
Yes. The intent of every design pattern should be paid more attention to than pattern itself.

Doug Wang.

[Shan Karawita]

Hi Alan,
Thank you so much for your clear explanation.

Shan Karawita