This week's book giveaway is in the OCAJP forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide 1Z0-808 and have Jeanne Boyarsky & Scott Selikoff on-line! See this thread for details.
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.
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.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
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.
Before you begin coding a particular design pattern for your problem, read the intent section of the Design Pattern to decide if it is applicable to your context.
Over-engineering will lead to the same problems as procedural code with no patterns at all. How do you know that you are not using too many patterns that are not required? The answer lies in the elegance of the resulting solution. Does it resolve the forces and fit your constraints well? It is elegant in the sense it helps us to conquer complexity instead of introducing unnecessary complexity.