Alan Shalloway

Although RUP could conceivably be done in an agile manner, one of the main proponents that the rational folks use with rup is that you are building models first, then developing code. This tends to be much more heavyweight than an agile process would be. The idea behind rup is often that if we go through our checklists and do what we are told, somehow the result with be one we like. That's because classical RUP is model and tool driven. There are many good things about rup, but the mindset should be agile to make it work.
Alan Shalloway

Matts said: "Also don't forget that a singleton constructor is private so inheritance from the singleton is not possible. Gotcha there right? "
Actually, the essence of a singleton is controlling the construction of the object. protected will work just fine for that so inheritance will work.
Singleton should be used when static methods won't - since static methods are easier.
Instead of asking which is better, ask what can one do that the other can't and do I need to do that?
Singleton can be modfied to allow for more than one instance, so if that's going to happen, you might want to start with using getinstance so you don't have to change it later. Also, with singleton, since you can get inheritance, if you need that, you should use it. If all you need is one instance of something and and static methods work - use them - it's simpler.
There is one other case I can think of, using a singleton can potentially control the order of when the object is instantiated better. With static methods, the static members will be instantiated the first time the class is referred to. This may be a reference to some const in the class. In the singleton pattern, it won't be instantiated until the getinstance is called.
------------------
Alan Shalloway.
Look for Jim Trott and my book: Design Patterns Explained
Visit our site Net Objectives.
Visit our Design Patterns Explained Community of Practice
Check out our CDROM based audio training in XML

This is a good example. You can see more on this in Bruce Eckel's free electronic book- Thinking in Java, 2nd Ed. Go to http://www.mindview.net/Books/TIJ/ He describes how Java's I/O is controlled with the decorator.

------------------
Alan Shalloway.
Look for Jim Trott and my book: Design Patterns Explained
Visit our site Net Objectives.
Visit our Design Patterns Explained Community of Practice
Check out our CDROM based audio training in XML

I hope this isn't considered too much of a plug, but since Jason mentioned he was in Denver, I wanted to point out that I'm doing a course in November, in Denver, on just this topic - a lightweight methodology very much like XP that takes advantage of Design patterns. See http://www.completeprogrammer.net/seminars/lpa.htm for information on it.
------------------
Alan Shalloway,
Look for Jim Trott and my book: Design Patterns Explained
Visit our site Net Objectives.
Visit our Design Patterns Explained Community of Practice
Check out our CDROM based audio training in XML

Kyle:
Thanks for mentioning my book, but it doesn't cover the state pattern. Your other recommendations are good.
------------------
Alan Shalloway,
Look for Jim Trott and my book: Design Patterns Explained
Visit our site Net Objectives.
Visit our Design Patterns Explained Community of Practice
Check out our CDROM based audio training in XML

It seems to me like you've got some of the characteristics of a composite pattern. Events may be broken down into other events, yet you want to treat all events the same. That is, you have a hierarchy (events), yet you want to be able to get rankings of individual events and grouped events.
MVC may be useful from the display point of view, but won't help you with the modeling of the events.
------------------
Alan Shalloway,
Look for Jim Trott and my book: Design Patterns Explained
Visit our site Net Objectives.
Visit our Design Patterns Explained Community of Practice
Check out our CDROM based audio training in XML

I've done my best to answer everyone's quesitons but I know I've missed many of them. Some were answered by others and I therefore didn't feel a need to add my two cents. However, if you felt I haven't gotten to you properly, please let me know on this topic. Please do not ask new quesitons here, just tell me which topic, date, and time you asked your question earlier so I can answer it there (as someone else may also be looking for it there).
Thanks, I've really enjoyed your questions and have had a great (although busy) week. After this week, please visit our site to continue to ask me questions. I'm sure I'll drop in on the ranch often enough however.
------------------
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
Check out our CDROM based audio training in XML

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

A high level approach I take when doing data mapping is to have a set of objects that acts as an intermediary between my in memory objects and my non-OO data. THis way, the rest of my system thinks it is dealing with an OO database, even though it is not. These layering objects are factories on one hand, creating objects from the database and updaters (for want of a better word) that move objects I need persisted into the rdbms. These layers aren't all that hard and are easy to maintain. It also allows me to write query objects that can work directly on the RDBMS. Relational databases have some really strong advantages if you don't need to worry about differences of the objects. For example, some applications I've worked on have had to worry about different nationalities. In my code, I'd use polymorphism to hide differences in tax rules, ... However, my databases typically could be easily split up so only data from one country was in any one data base. This allows for quick queries and extractions to be done in the RDBMS itself.
------------------
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

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

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

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

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

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

My opinions of the books out there. Obviously, I'm biased.
I picked up the following books on my shelf:
Design Patterns Explained: A New Perspective on Object-Oriented Design. In my not so humble opinion, the first book to read on patterns. If you want to start somewhere else, read Peter Coad's Java Design which incorporates many ideas of patterns without mentioning them.
Design Patterns: Elements of Reusable Object-Oriented Software. Still the best book on patterns. Get a copy, the C++ is not that hard to read. Get a copy of Grand's patterns in Java book if you want examples.
A Timeless Way of Building by Christopher Alexander. This is the architect's book that started it all. Read it. It is both interesting from a technical and non-technical way. My wife enjoyed this and she is a psych counseler in our public education system.
Refactoring - A great book. Although focused on good coding practice, patterns and coding practice go hand in hand. I've seen that if you follow three rules: once and only one, high cohesion, loose coupling, you will often end up with patterns.
Pattern-Oriented Software Architecture: Vol 2, Patterns For Concurrent and Networkd Objects. Its roots are in C++ and Corba but this is a great book for anyone dealing with multithreading. Examples are in C++ however.
Pattern-Oriented Software Architecture: Vol 1. A good secondary book on patterns. No code examples but good discusions of many patterns. Quite a lot of overlap between GoF book. A must have for a departmental library.
Grands Java Patterns - good secondary book. Definitely should be available at the department level.
Cooper's Java Patterns: A Tutorial - avoid this or get the on-line copy.
------------------
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