File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes OO, Patterns, UML and Refactoring and the fly likes Is there any easy way? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Murach's Java Servlets and JSP this week in the Servlets forum!
JavaRanch » Java Forums » Engineering » OO, Patterns, UML and Refactoring
Bookmark "Is there any easy way?" Watch "Is there any easy way?" New topic
Author

Is there any easy way?

Vedhas Pitkar
Ranch Hand

Joined: Jan 27, 2001
Posts: 445
Hi,
I have read GOF's Patterns & the J2EE Patterns.Initially, I can remember what pattern is used for what but after a while all the patterns seem same to me.Faced a lot of problems during interviews as well.So for interview purposes had to limit my knowledge of patterns to only Abstract Factory & Singleton(they being the easiest ) Is there any easy way of remembering all the 23+J2EE Patterns ?
Sathya Srinivasan
Ranch Hand

Joined: Jan 29, 2002
Posts: 379
Recently, I interviewed around 15 people for my company. When I asked them what design patterns they used in their projects ALL of them said that they used "Factory" and "Singleton"! Maybe there is a method to the madness!


Cheers, Sathya Srinivasan - SCJP 1.2, SCWCD 1.2, SCMAD 1.0
Co-Author of Whizlabs SCMAD Certification Exam Simulator and SCMAD Exam Guide Book
Elisabeth Robson
author
Ranch Hand

Joined: May 14, 2004
Posts: 173
    
    6
That's really interesting! I have to admit, I've asked questions in interviews about Singleton a lot. No idea why I picked that one.

I think that, like anything else, it's hard to remember something if you don't USE it often. However, remember those Head First learning principles - the best way to learn something and make it STICK is to make learning fun.

A few people on this group have recommended patterns study groups as a good way to learn and remember patterns, and I heartily agree. I'd also say, if you have time, to try to come up with your own fun program examples to use patterns, or if you're working on a problem try to think about each pattern and if it would apply. Not necessarily that you'd actually implement it, but just think about it.

Elisabeth


Co-Author of Head First JavaScript Programming
Mike Farnham
Ranch Hand

Joined: Sep 25, 2001
Posts: 76
And, remember, the GoF book is a catalogue of patterns, a reference book. Refer back to it often.

I wonder, what would somebody think if you brought the GoF book to an interview?

Or, better yet, the HF book!!
Nicholas Cheung
Ranch Hand

Joined: Nov 07, 2003
Posts: 4982
At least, you should know the most common patterns, including MVC, DAO, Service Locator. And more often, you really need to have some experiences on these patterns, not just read a book, load the content, and then go to the interviews.

Nick


SCJP 1.2, OCP 9i DBA, SCWCD 1.3, SCJP 1.4 (SAI), SCJD 1.4, SCWCD 1.4 (Beta), ICED (IBM 287, IBM 484, IBM 486), SCMAD 1.0 (Beta), SCBCD 1.3, ICSD (IBM 288), ICDBA (IBM 700, IBM 701), SCDJWS, ICSD (IBM 348), OCP 10g DBA (Beta), SCJP 5.0 (Beta), SCJA 1.0 (Beta), MCP(70-270), SCBCD 5.0 (Beta), SCJP 6.0, SCEA for JEE5 (in progress)
Sathya Srinivasan
Ranch Hand

Joined: Jan 29, 2002
Posts: 379
To add on to that,

During the process of interviewing, when I started asking people to explain design patterns, almost everyone gave examples from the Core J2EE Patterns (Almost all of them mentioned DAO and Value Object). On the same note, when I asked if they knew any of the GoF patterns, most of them mentioned "Singleton" and "Factory" but could not go beyond that.

This kind of disturbs me. It looks like people want to know a few patterns because it's 'cool' to mention them in the passing, but don't really take time to understand why they are there in the first place.

I hope a clearer understanding of the basics by reading HFDP helps alleviate this issue
Udayan Patel
Ranch Hand

Joined: Oct 14, 2004
Posts: 94
Originally posted by Sathya Srinivasan:
To add on to that,

During the process of interviewing, when I started asking people to explain design patterns, almost everyone gave examples from the Core J2EE Patterns (Almost all of them mentioned DAO and Value Object). On the same note, when I asked if they knew any of the GoF patterns, most of them mentioned "Singleton" and "Factory" but could not go beyond that.

This kind of disturbs me. It looks like people want to know a few patterns because it's 'cool' to mention them in the passing, but don't really take time to understand why they are there in the first place.

I hope a clearer understanding of the basics by reading HFDP helps alleviate this issue


I have started on design patterns back from 2001. And this is 2004 rather almost 2005. within last two years there wasn't a single time where I had to decide to use composite or Strategy or Memento or Flyweight or Bridge or Prototype or Decorator. 2002 and 2003 was maintenance of the project that was written using design patterns. Last year there was no single instance where I had to use any of the complex DPs. often I have used very basic DPs like Factory, Singleton, Template Method in this year. well one instance each of Adaptor and interpreter. but other than that NO because didn't needed.
Mark Spritzler
ranger
Sheriff

Joined: Feb 05, 2001
Posts: 17249
    
    6

To add some other common patterns used.

Command
Facade
Iterator
Observer

sometimes Visitor.

Those are the ones that I definitely face every day, besides Factory. Singleton is a good one to test for, because it is overused.

Mark


Perfect World Programming, LLC - Two Laptop Bag - Tube Organizer
How to Ask Questions the Smart Way FAQ
Elisabeth Robson
author
Ranch Hand

Joined: May 14, 2004
Posts: 173
    
    6
There are definitely patterns which are more used than others! It's interesting to hear which patterns people use the most. We looked at which patterns were used the most before writing the book and did in-depth coverage of the most used patterns. So far, that seems to correspond pretty well with my experience and other people's experience.

Elisabeth
Elisabeth Robson
author
Ranch Hand

Joined: May 14, 2004
Posts: 173
    
    6
There is a poll here: http://faq.javaranch.com/view?DesignPatternsPoll

Take the poll so we can see how many people use which patterns!

Elisabeth
Bert Bates
author
Sheriff

Joined: Oct 14, 2002
Posts: 8801
    
    5
For what it's worth, the Decorator will play a role in studying for two of the Sun certifications!


Spot false dilemmas now, ask me how!
(If you're not on the edge, you're taking up too much room.)
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
Hmmm, I use command, factory method, strategy and observer quite a bit, visitor less but I like em.

I'd be more interested in OO principles (see Robert Martin's Agile Software Development for a catalog) than GoF patterns if I were interviewing. Some GoF patterns ought to show up when talking about those, too.
[ December 01, 2004: Message edited by: Stan James ]

A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Bert Bates
author
Sheriff

Joined: Oct 14, 2002
Posts: 8801
    
    5
IMHO Eric and Beth do an awesome job of using OO principles to explain why these patterns work so well, it's almost "Stealth HF OO via Patterns"
Michael Sullivan
Ranch Hand

Joined: Dec 26, 2003
Posts: 235
Speaking of making it stick, does HFDP have sample code (the like of the mini-MVC tutorial in HFservlets) for the patterns?
Corey McGlone
Ranch Hand

Joined: Dec 20, 2001
Posts: 3271
Not too long ago, I reviewed a book called Refactoring to Patterns. This text took the concept of refactoring to the next logical step - applying various refactorings in a certain order to alleviate certain problems that led to the introduction of design patterns.

I don't know that it's a great way to learn design patterns, but it was a little different "spin" to the process. You started with a problem that you wanted to solve and then worked to improve the code to fix it and, in the process, introduce a new pattern to the mix. It was a good book and quite possibly worth a read.

My problem with patterns is that I'll read all about them and then never use them and, before I know it, I've forgotten them all except a few basics that I've used in the past, such as the Singleton and Factory patterns. It seems I'm not the only one in that boat.

The key to remembering something you've just learned is reinforcement. Maybe I need to find a buddy at work and consistently look at the design of our code to see how it can be improved.


SCJP Tipline, etc.
Vedhas Pitkar
Ranch Hand

Joined: Jan 27, 2001
Posts: 445
Some time ago we were doing a maintenance project in which we found there were design patterns used but it was a very difficult task to identify the patterns from the code due to the similarity between some of the patterns. I think OO principles play as important a role as patterns do.
Elisabeth Robson
author
Ranch Hand

Joined: May 14, 2004
Posts: 173
    
    6
To answer a couple of questions...

Yes, HFDP does have sample code - lots of it! We have different examples in each chapter. We tried hard to come up with examples that are in-depth enough you'll see the pattern at work, but not so complicated that you get lost in trying to understand the examples. Hopefully we succeeded!

Regarding learning and remembering the patterns, like anything else, it's hard to remember something if you don't use it. But you know, that's ok... the thing about patterns is that you don't *have* to remember them all, because you've got reference books like the Gang of Four patterns catalog to help when you need to jog your memory about a specific pattern, and learning books like Head First Design Patterns when you need to jog your memory about how to use a pattern.

I think as long as you've learned enough about patterns to know (1) how to understand them and apply them (2) how to recognize them when you see them (even if you have to look them up to remind yourself exactly which one it might be) and (3) know enough about the design principles and good design structure so that you recognize a situation when you need to rework your code to make it better, then it's really ok not remember them all.

And most people work in specific domain areas, so you will probably find that you'll need and use a few patterns much more often than the others, so of course those are the ones you'll remember best.

Elisabeth
Sathya Srinivasan
Ranch Hand

Joined: Jan 29, 2002
Posts: 379
Originally posted by Stan James:

I'd be more interested in OO principles (see Robert Martin's Agile Software Development for a catalog) than GoF patterns if I were interviewing. Some GoF patterns ought to show up when talking about those, too.


Ha! I asked about OO Principles (like Open-Closed) and even gave some simple problems to make them say that it violates one of the principles, but none of them even knew that there was something called 'OO Principles'. I also have to say that I came up with those questions a few months back after I read the Martin book as a part of my study group. It was an eye-opener!
Elisabeth Robson
author
Ranch Hand

Joined: May 14, 2004
Posts: 173
    
    6
That's interesting! I haven't asked questions specifically about design principles in interviews before although questions related to them. However, since writing HFDP, I think I probably would too, because it's much clearer to me now (having written about them) how they fit into the big picture of design.

Even if someone were not specifically familiar with a given concept as a principle, you could still ask them a question about it - give them the principle and ask them how they think it might be important in a design problem, for instance.

Elisabeth
Corey McGlone
Ranch Hand

Joined: Dec 20, 2001
Posts: 3271
Originally posted by Elisabeth Freeman:
Even if someone were not specifically familiar with a given concept as a principle, you could still ask them a question about it - give them the principle and ask them how they think it might be important in a design problem, for instance.


Indeed - I wouldn't jump to any conclusions about someone if they didn't know an exact "term" or "catchphrase." I had a professor in college (he had a PhD and was an expert in "fuzzy logic" databases) from whom I was taking a relational database class. He recalled being in an interview when they asked him about "sequel." He had no idea that they were talking about SQL because he had never heard it pronounced in such a way. To him, it had always been S.Q.L.

Additionally, I think it would be unwise to discount someone because he hasn't read the same book as you or follow the same methodology as you. Just because you're an XP expert doesn't mean everyone you hire needs to be, right? (Ok, if you're recruiting to write a book on XP, maybe you have a point.) Certainly, Fowler is well respected in the industry and his publications are read by a lot of people, but don't shoot someone down because he doesn't know Fowler's terminology.

I think it's more important that a person has a solid understanding of the concepts, not the names of the principles given by other folks. Everyone's experience varies.
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
Good point - asking about the principles and patterns by name tells you one thing. Asking how to solve a problem might tell you another. Back when I started teaching my dad reminded me that a test tells you three things: How good was the test, how good was the teaching, and how good was the student at predicting the test. Probably in that order.

In a recent round of interviews we described a problem - a need for polymorphic behavior around DTOs that had no behavior at all. A couple people came up with something like the strategies we use without using the word strategy.
Sathya Srinivasan
Ranch Hand

Joined: Jan 29, 2002
Posts: 379
Originally posted by Corey McGlone:


Indeed - I wouldn't jump to any conclusions about someone if they didn't know an exact "term" or "catchphrase."


Oh, absolutely. My intention was never to get the words "open-closed principle" out of the person's mouth. That would be pretty bad, given the fact that I became familiar with the terms only after reading Martin's book 3 months back.

I mostly tried to give some simple scenarios that could potentially violate the principles and to find out if they could smell it. Also, I was giving some questions where I wanted answers like "I would prefer an interface over concrete implementation", etc.
Vedhas Pitkar
Ranch Hand

Joined: Jan 27, 2001
Posts: 445
Originally posted by Elisabeth Freeman:
That's interesting! I haven't asked questions specifically about design principles in interviews before although questions related to them.


If you come to India & appear for a Java job interview you'll be surely 100%asked DP questions.Asking patterns related questions is not a bad idea,but more emphasis should be on HOW the candidate solves a given problem
 
It is sorta covered in the JavaRanch Style Guide.
 
subject: Is there any easy way?
 
Similar Threads
Head First Software Development (2007)
Basic Doubts in Design Patterns
notes on Design Patterns
Good books for EJB and Design patterns
New to design patterns