• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Design Patterns

 
Greenhorn
Posts: 10
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I have to design a class that has to run on the caller's thread and should also have some business intelligence built in that.Am using jdk 1.1 as it is what is right now supported by the environment that I work. The class that I have to design should be modal in function. The UI part however is decoupled from the class.The class will accept a pin and check for the validity for the pin or update a changed pin or store a new pin. I would like to know if there are any design patterns that are available for this scenario.

Thanks in advance.
 
Ranch Hand
Posts: 79
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Bill Venners: Is the value of patterns, then, that in the real world when I feel a particular kind of pain I'll be able to reach for a known solution?

Erich Gamma: This is definitely the way I'd recommend that people use patterns. Do not start immediately throwing patterns into a design, but use them as you go and understand more of the problem. Because of this I really like to use patterns after the fact, refactoring to patterns. One comment I saw in a news group just after patterns started to become more popular was someone claiming that in a particular program they tried to use all 23 GoF patterns. They said they had failed, because they were only able to use 20. They hoped the client would call them again to come back again so maybe they could squeeze in the other 3.

Trying to use all the patterns is a bad thing, because you will end up with synthetic designs�speculative designs that have flexibility that no one needs. These days software is too complex. We can't afford to speculate what else it should do. We need to really focus on what it needs. That's why I like refactoring to patterns. People should learn that when they have a particular kind of problem or code smell, as people call it these days, they can go to their patterns toolbox to find a solution.



How to Use Design Patterns,A Conversation with Erich Gamma ..

This article is very instructive about the use of patterns : Use them to solve a problem when refactoring your code.

So the best way to find the pattern to apply is knowing to problem you are facing. So what is the exact problem ?
 
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by raphael Bereh:

Use them to solve a problem when refactoring your code.



Good point! See also http://faq.javaranch.com/view?WhenToApplyDesignPatterns
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by raphael Bereh:

How to Use Design Patterns,A Conversation with Erich Gamma ..

This article is very instructive about the use of patterns : Use them to solve a problem when refactoring your code.



Very good article - thanks for the pointer!
 
Ranch Hand
Posts: 1683
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
So, you are writing a business object. A good design principle is to disassociate your business object from the client, so it matters not the slightest whether that client is a browser, servlet, Struts Action class, Swing class, EJB or whatever. The business delegate pattern is used in this scenario.

Your business object has to access some persistant store, perhaps a file or a database. The implementation of that store should be transparent to the business object, so the Data Access Object pattern can be used.

In summary, your design can look like this.

Client --> Business Delegate --> Business Object --> DAO --> Store

Note that there is not necessarily one right solution, but I believe that you won't be far wrong if you did something as outlined above.
 
Ranch Hand
Posts: 60
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
This is what I say:

"An intelligent programmer always discovers patterns himself/herself. Eric Gamma should always be a deja vu."
[ June 16, 2005: Message edited by: praveen balaji ]
 
Sheriff
Posts: 4313
Android IntelliJ IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
This is a great conversation.

I'm going to move it to the OO, Patterns, UML and Refactoring forum so that other people interested in patterns can benefit from it.

So please post your replies here. Thanks!
[ June 16, 2005: Message edited by: Jessica Sant ]
reply
    Bookmark Topic Watch Topic
  • New Topic