Thanks - J2EE Design Patterns Applied

[John Carnell]

Hi guys,
Today is the last day of my J2EE Patterns Applied book promotion. I just wanted to thank everyone who participated in the discussion thread I had going. It was a blast and I was impressed with everyone's willingness to share information without being judgemental.
I will be hanging around the Java Ranch from time to time and checking the postings. I would like to leave everyone with last question that we can mull on and it is a question I have struggled with in the past.
As an instructor I have often seen object-oriented analysis classes taught with almost no references to design patterns. They usually focus on the semantics of drawing class diagram, sequence diagrams,etc..... Should design patterns be integrated into the base OO curriculium? In addition, should design patterns be incorporated into the classes on particular programming languages?
Right now I teach a distributed Java programming class. One of the main tenets of the class is that I will try to teach people not only the mechanics of the language, but also how to apply the language to solve problems.
I am interested in hearing anyone's opinion on the subject. :>

Thanks,
John

[Malay Thakkar]

Hi John,
It was really pleasure having talk with you.It was really a knowledgeable session.And very helpful to all who participated and will go through this thread.
I can give you an instance recently we had and external training Faculty who had come to our firm to teach all the new joiners about OOAD,UML and Unified Process.I asked him what all he is going to cover in the curriculum.He told he will teach OO terminologies,UML concepts,Use Cases,Sequence Diagrams,Collaboration Diagrams,Deployment Diagrams,Package Diagrams.Also there will be hands on with case tool like Rational Rose.Then I asked him how about design patterns.He told me that it is more advanced topic, even though considering the fact that he was suppose the address all the developers who were having minimum of 2yr of Experience in Java technology.I felt at that moment that really then the course is of no real help.Anyone can catch a book and practice on Rational Rose and master the tool.The real part is to cultivate the habbit and tune the thought process to Applying Design Patterns more efficiently.
It is more important to start your thought process in terms of applying design patterns given a particular scenario.Once this discipline is imbibed early in your career the more efficient and clear you can become.So depending on the language it should be customised and applied.
Best Regards
Malay

[Tim Holloway]

Personally, I've been baffled by the fact that job ads demand all sorts of experience in UML (generally on specific name-branded tools with no substitutions allowed) and place unbelievable emphasis on Use Cases. At the same time, nary a peep on Design Patterns.
I think a good analogy for a more primitive day would have been a demand for expertise in flowcharting symbols (using a specific brand of template, of course ) while ignoring proven ways of combining them to do effective programming. After all, while UML is used to illustrate Design Patterns, unpatterned UML might as well be spaghetti code. And, considering the greater complexity of modern-day systems, probably is just about the same burden.
On the other hand, I've become embittered and cynical about a world that seems to be more interested in cheap software that doesn't work right than something designed to perform properly and well. So'd I'd recommend you write your next book on Developing Sloppy Web Applications Quickly and Cheap Using RUP or something equally specious.
You'll probably sell more copies

[Leslie Chaim]

Hi John,
I did not have the time to follow all of the discussions this week, I will have to come back a review them at my time. I did find your questions very enlightening and wanted to have at-least have a say, here are my thoughts:

it is a question I have struggled with in the past.

Great, I hope that the following will make sense to you
First, let me say that my learning focus has always been on implementation, in other words "getting it done". I started 5 years ago with IT and now I am starting to move to the abstracts of UML, patterns, and OO. I believe that was my surest way to find a job. I think Tim will agree with that . It would come then as no surprise to you that my favorite language is Perl, and I don�t think it will change esp. if we like freedom. I am from the self-taught school and mostly through books. Occasionally, I attend a short course when I feel I need an instructor's interaction.
I preface all of this since you mentioned being an instructor so I just wanted to share my learning experience. Also, I want to hear your general comments on this. I will give my opinions starting from the implementation thoughts, which you happen to mention last in your post, but is most relevant to me.

One of the main tenets of the class is that I will try to teach people not only the mechanics of the language, but also how to apply the language to solve problems.

I don't think that this has anything with including patterns in OOAD classes. However, the ability to apply a language is very important, everyone know that. No, I do not mean to re-phrase you � After I taught myself Java, with the only purpose to pass the exam, I was very surprised that despite passing, I could not effectively apply the language to real problems. OK, I will admit that I did NOT practice anything. I just studied and went for the test writing less the fifty lines of Java. Nevertheless, applying skills in Java does require additional focus, and perhaps its own study, even if one know all of its mechanics.

�
I have often seen � focus on the semantics of drawing class diagram, sequence diagrams,etc..... Should design patterns be integrated into the base OO curriculium?

You mention three things here:

drawing class diagram, sequence diagrams

design patterns

the base OO

John, please help me out, I am learning here: Is it correct to say that you have here UML followed my Design Patterns followed by OO? In other words, does one builds on top of the other and therefore one should be trained in that order?
I believe it does, and as Malay is saying that the course with all the bells and whistles was useless when it came to applying.
After I got some of the OO and Java skills, I realized I needed to acquire more knowledge. I thought that UML should be next. From all the books, I chose Martin Fowler's UML distilled. It appears to me that I should have started first with the Pattern studies esp. that within UML you refer to a given design pattern.
I think it depends whether you're teaching OO from a design or implementation prospective. OO design courses should includes Patterns while OO implementation courses should focus on applying a language techniques.

should design patterns be incorporated into the classes on particular programming languages?

Yes! I think it�s a fantastic idea. Of course you will not have to use it but I think that it�s another step to have plug 'n' play software.
Finally, let me ask you what book would you recommend as my first design patterns book. I usually get about 2-4 books on a topic and your book just seems too big for a start (to buy that is � if I win a copy then it would be my first ). I guess I am looking for a "Design Patterns distilled" as written by Fowler on UML, 200 pages and � useful.
Thanks in advance for your thoughts,
Leslie
[ October 04, 2002: Message edited by: Leslie Chaim ]

[John Carnell]

Hi Leslie,
Its been my experience that people are taught in their classes the basics of UML and the basics of an OO language. (What is polymorphism, what is inheritance....?) Unfortunately, the problem is that these classes do not go beyond this and often leave the student to learn how to apply OO solutions on their own.
I think this is one reason why Design Patterns should be introduced in the OOAD classes. They offer many practical examples of the practical application of OO design.
However, I do think your comments are well-placed. Believe it or not the J2EE Design Patterns book is one of the smaller books on design patterns. :,> (I keep a copy of Fowler's UML book on the). I think you'll find though that the book is pretty approachable with the material supported with code examples and discussion.
Thanks for the comments (They were useful),
John Carnell

[John Carnell]

Hi Tim,
I feel your pain (To quote one of our ex-presidents). Its interesting you bring up the sloppy code thing right now. My current book project is a book on web anti-patterns and solutions.
Thanks,
John

[Fintan Conway]

Hi John,
We also had a consultant in to teach us UML. This was done as part of walking us through a particular live project to teach us how to apply RUP. OOAD was broken into OOA and OOD.
In OO Analysis - before we even looked at UML semantics or drew any diagrams we looked at the Use cases and selected out of them (i) Boundary classes, (ii) Controller classes and (iii) Entity classes. This jumped out at me as the MVC pattern (Model = Enity class, View = Boundary class, Controller = Controller class). There was no mention of patterns at this stage. I believe it would only have caused confusion. We are now automatically using this "MVC pattern" throughout our organisation - although we call it our Analysis process.
Good code which does what the customer wants, is efficient, reliable and scalable can be written without applying patterns. I think people need to learn to walk before they run. When people are comfortable using UML then teach them to use UML "even better" by applying the patterns.

This poses another question : Is there a difference between Analysis patterns (architecture neutral) and Design patterns (implementation specific)? I have not heard of Analysis patterns. People always talk of design patterns.
Cheers - enjoyed the posts,
Fintan

Originally posted by John Carnell:
Hi guys,
As an instructor I have often seen object-oriented analysis classes taught with almost no references to design patterns. They usually focus on the semantics of drawing class diagram, sequence diagrams,etc..... Should design patterns be integrated into the base OO curriculium? In addition, should design patterns be incorporated into the classes on particular programming languages?
One of the main tenets of the class is that I will try to teach people not only the mechanics of the language, but also how to apply the language to solve problems.