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 Design Patterns Study Group Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Spring in Action this week in the Spring forum!
JavaRanch » Java Forums » Engineering » OO, Patterns, UML and Refactoring
Bookmark "Design Patterns Study Group" Watch "Design Patterns Study Group" New topic
Author

Design Patterns Study Group

Prithvi Sehgal
Ranch Hand

Joined: Oct 13, 2009
Posts: 774
Dear All,

I am planning to have an extensive study on Design pattern and their implementations specially the ones which are present
in Head First Design Patterns. I was planning to have a study group in that context. Please let me know who else is in. It can
be very informative. We can have this group on here at this forum. Let me know.

BR,


Prithvi,
My Blog, Follow me on Twitter,Scjp Tips, When you score low in mocks, Generics,Scjp Notes, JavaStudyGroup
jeffery thomas
Greenhorn

Joined: Sep 13, 2011
Posts: 1
I'm in!

I've actually started this book and am currently working on the Observer Pattern. I have worked with java before, but am having problems with some the the java code examples in the book.

Looking forward to this group.

jeff
Jeanne Boyarsky
author & internet detective
Marshal

Joined: May 26, 2003
Posts: 30764
    
156

I think it will be an interesting experiment to see this in the forum.


[Blog] [JavaRanch FAQ] [How To Ask Questions The Smart Way] [Book Promos]
Blogging on Certs: SCEA Part 1, Part 2 & 3, Core Spring 3, OCAJP, OCPJP beta, TOGAF part 1 and part 2
Prithvi Sehgal
Ranch Hand

Joined: Oct 13, 2009
Posts: 774
Hey,

Thanks guys for showing the interest. Lets pick up two patterns each week with some proper use-case to implement.
Lets keep Strategy, Command Pattern this week as these two ones are very similar. Let me know the suggestions how
we can proceed with this exercise Jeff.

BR,
Alexander Sales
Ranch Hand

Joined: Feb 21, 2011
Posts: 89

I'm in! I have been reading the Head First designs pattern book too..


OCPJP 6, OCEWCD Java EE 6
Prithvi Sehgal
Ranch Hand

Joined: Oct 13, 2009
Posts: 774
Hey Alexandar,

Lets come up with a Plan. What about Strategy and command pattern this week? Let me know so that i can escalate
a link by which we can study and there is a working use-case which we can implement to get a proper understanding
of the pattern.

BR,
Alexander Sales
Ranch Hand

Joined: Feb 21, 2011
Posts: 89

sure! i am always online around this time...
Priyanka Chaurishia
Greenhorn

Joined: Oct 12, 2011
Posts: 9
Hey this is my first post to the forum. It would be nice to have a study group.
Jan Cumps
Bartender

Joined: Dec 20, 2006
Posts: 2503
    
    8

Welcome to our Ranch, Priyanka!


OCUP UML fundamental and ITIL foundation
youtube channel
Yogesh Gnanapraksam
Ranch Hand

Joined: Dec 17, 2009
Posts: 133
Why don't we start by identifying the real application scenarios where these patterns are used ?
Prithvi Sehgal
Ranch Hand

Joined: Oct 13, 2009
Posts: 774
Hi,

Many people here are not really acquainted with design Patterns, so first without knowing the design pattern itself, it would be hard
to identify scenarios even.

BR,
Ryan McGuire
Ranch Hand

Joined: Feb 18, 2005
Posts: 1010
    
    3
Prithvi Sehgal wrote:
Many people here are not really acquainted with design Patterns, so first without knowing the design pattern itself, it would be hard
to identify scenarios even.


It is a bit of a chicken-and-egg problem. It's hard to study Design Patterns well until you can come up with a scenario where they might be used, but it's hard to come up with an appropriate scenario for a given DP until you've studied it a bit.

One option would be to just copy a scenario from a book, even if you don't quite understand the pattern enough to see how it applies. That will at least give you a starting point. Another option is to discuss a little theory behind each Design Pattern first, free from any real-world examples, and then see if that discussion will help the group come up with scenarios where the pattern could be applied.


Another thought: Two design patterns a week might be a bit aggressive. I'd suggest trying to cover at most one each week. Your call.

Yogesh Gnanapraksam
Ranch Hand

Joined: Dec 17, 2009
Posts: 133
Agree with Ryan....
Well..why don't we start..which pattern first ? ...strategy ?
Jimmy Clark
Ranch Hand

Joined: Apr 16, 2008
Posts: 2187
Before starting to study any specific design pattern, your group should establish a "common definition" of what an object-oriented design pattern is and how patterns are used in general. A common understanding will help you communicate more effectively. As you explore specific details of specific patterns there may be some disagreements amongst you, but a common foundation of what a design pattern is will help you.

Good luck!
Yogesh Gnanapraksam
Ranch Hand

Joined: Dec 17, 2009
Posts: 133
Ok.Thanks Jimmy for pitching in at the right time..

From what I understand based on my exposure to design patterns...
Design pattern is a common solution to a recurring problem and it applies to any engineering field.

If we are aware of the recurring problems encountered in designing object oriented systems ,then we will understand the need for patterns.




Regards
Yogi

Jimmy Clark
Ranch Hand

Joined: Apr 16, 2008
Posts: 2187
Sounds good. However, I would not consider an object-oriented design pattern to be a "solution." It is more of a guide that may help with implementing a "solution." It is the outcome of the implementation that determines if there is a "solution" or not. And since there can be many different types of implementations for a particular pattern, there is no guarantee of a solution simply based soley on usage of a design pattern guide itself.

An object-oriented design pattern must include documentation. It provides a design template which contains design strategies for a specific and common computing task.
vinny kapoor
Greenhorn

Joined: Apr 05, 2008
Posts: 13
Hi All,

Good to see this forum. Why don't we start with a small application and use various possible design patterns as we go along.
Any takers?

vinny
Yogesh Gnanapraksam
Ranch Hand

Joined: Dec 17, 2009
Posts: 133
I agree to anything that keeps us moving forward...something that reminds us to visit the group daily and keep posting in it.

Suhas Mandrawadkar
Ranch Hand

Joined: Jul 21, 2007
Posts: 72

I think I have arrived here at the right time ..


Regards, Suhas S. Mandrawadkar.
Certifications: SCJP 6, SCWCD 5, Oracle WebLogic Server Administrator, OCE Java EE 6 EJB Developer
Melisa Reyes-Stewart
Greenhorn

Joined: Nov 09, 2011
Posts: 1
Hi folks! Wondering if this has started yet and what the right way was to get plugged in.
Thanks!
- Melisa
Prithvi Sehgal
Ranch Hand

Joined: Oct 13, 2009
Posts: 774
Hi,
This has not yet started. Lets follow Head first design patterns, try to search some scenario and implement it. We can keep a common place
to create notes or reference to scenarios or even sample code. I volunteer my blog for it.

BR,
Piyush Joshi
Ranch Hand

Joined: Jun 10, 2011
Posts: 207

Hi, just started reading Head First Design Patterns and stumbled upon this post.
But sad to see that after almost two months of starting the group nothing fruitful has come.
I am in, to actively participate in such a group.
To start lets focus on Strategy Pattern which is first pattern from Head First Design Patterns book.


Piyush
Yohan Weerasinghe
Ranch Hand

Joined: Oct 07, 2010
Posts: 499

I am in... So, what should we do?


Are you better than me? Then please show me my mistakes..
Piyush Joshi
Ranch Hand

Joined: Jun 10, 2011
Posts: 207

First we should layout some ground work for discussion.
I will start with formal definition and then examples of scenarios where we can use Strategy Pattern.

To begin with here is the formal definition:
"Define a family of algorithms, encapsulate each one, and make them interchangeable. Strategy lets the algorithm vary independently from clients that use it."

Some Examples of using Strategy Pattern (I collected them from top 10 google results for Strategy Pattern):

1. Family of algorithms: SortingStrategy interface (represents family of Sorting algorithms to sort a list)
Encapsulates each one: QuickSort, MergeSort implementations of SortingStrategy.
Makes them interchangable: SortedList class having a property of type SortingStrategy.
(source: http://www.dofactory.com/Patterns/PatternStrategy.aspx )

2. Family of algorithms: TransportationMode interface (represents family of transportation modes available from airport)
Encapsulates each one: PersonalCarMode, TaxiMode, CityBusMode etc. implementations of TransportationMode
Makes them interchangable: property of type TransportationMode in class TransportationToAirport
(source: http://sourcemaking.com/design_patterns/strategy )

3. Family of algorithms: RobotBehaviour interface (represents family of robot behaviours)
Encapsulates each one: AggressiveBehaviour, DefensiveBehaviour, NormalBehaviour etc. implementations of RobotBehaviour
Makes them interchangable: property of type RobotBehaviour in class Robot
(source: http://www.oodesign.com/strategy-pattern.html )

4. Family of algorithms: Border interface (defines family of borders for a Swing component)
Encapsulates each one: BevelBorder, CompoundBorder, EmptyBorder, EtchedBorder, LineBorder, TitledBorder etc. implementations of Border
Makes them interchangable: property of type Border in class JComponent
(source: http://www.javaworld.com/javaworld/jw-04-2002/jw-0426-designpatterns.html?page=2 )

5. Family of algorithms: ShootingBehaviour interface (defines family of shooting behaviours for a shooting game unit)
Encapsulates each one: GunShoot, ThrowKnives, CantShoot etc. implementations of ShootingBehaviour
Makes them interchangable: property of type ShootingBehaviour in class GameUnit
(source: http://www.cumps.be/nl/blog/read/design-patterns-strategy-pattern )

As far as my understanding Strategy Pattern defines a level of abstraction between a concrete Strategy(implementation) and users of the Strategy. Thus enabling users to afford loose coupling with implementation which results in replacable or exchangable implementations.

Further Reading:

Definition of some terms (source: http://www.oodesign.com/strategy-pattern.html ):
Strategy - defines an interface common to all supported algorithms. Context uses this interface to call the algorithm defined by a ConcreteStrategy.
ConcreteStrategy - each concrete strategy implements an algorithm.
Context -
-contains a reference to a strategy object.
-may define an interface that lets strategy accessing its data.
The Context objects contains a reference to the ConcreteStrategy that should be used. When an operation is required then the algorithm is run from the strategy object. The Context is not aware of the strategy implementation. If necessary, addition objects can be defined to pass data from context object to strategy.

also see : http://sourcemaking.com/design_patterns/strategy
Piyush Joshi
Ranch Hand

Joined: Jun 10, 2011
Posts: 207

I guess that's a lot of information to digest at a time. I should have gone for a more general explanation.

So I will start again with most fundamental questions:

What is a design pattern? Why should I use them?
- As far as I understand, design pattern is a common and recurring way to solve a common and recurring problem. So what are the recurring problems that we face in software development?
When we start the development we have certain set of requirements that our software needs to fulfill. Those requirements are almost always inconsistent or keep on changing. Even if the requirements don't change during the development, they can change after the development, for example addition of a new feature or modification or removal of an existing feature etc.
But what's the problem we can change our code to do whatever we want it to do, so any changes should not be of much problem.
However the cost to change can be great both in terms of money and time or effort. So our problem area is that we need to minimize the cost or effort it takes to change the behavior of our application.
How can we do that? By implementing flexibility, reuse etc.. Design patterns help us achieve these goals. In general, they help us localize the changes to a smaller part of the application keeping larger part unchanged.

How do design patterns add flexibility to the design?
- Design patterns are based on good OO practices known by experience, and time-tested by developers. Applying good OO principles leads to more flexible and maintainable systems.

How to use these patterns?
- Each pattern addresses a certain problem. So first we need to find out what the problem is, that we are trying to handle. This can be done by foreseeing (or assuming?) the changes that can come in future and how you will implement those changes. How do we know we have a problem? We have got a problem when answer to any of these questions is a no: Will the implementation of a change be easy? or Can I implement the changes without redesigning my application? and similar to those. After we recognize the problem we need to find which design pattern(s) address the problem. Finding a relevant pattern is a relatively easy exercise.

These are my views on these fundamental questions. Please share your views or point out any mistakes in my understanding.

Also to keep moving forward we can start with a similar discussion on Strategy Pattern.
Prithvi Sehgal
Ranch Hand

Joined: Oct 13, 2009
Posts: 774
Hi Piyush,

This is a good understanding of what a design pattern is. I guess this is a sufficient explanation for a novice to know what a design pattern is.
Our main approach should be to decide one or two patterns per week, which should cover these following ideas

1- Main background of that pattern, why and where it should be used?
2- Picking up a common scenario.
3- Implement the scenario and have a general discussion of how to improved it

For a perfect understanding, i believe that, we need to implement it, what do you think?

BR,
Piyush Joshi
Ranch Hand

Joined: Jun 10, 2011
Posts: 207

I think two patterns per week will be good, and for the implementation part I agree with you, it will surely improve our understanding.

So lets start. Which two this week? I vote for Strategy and Decorator patterns. They both are quite similar and related, so learning them together will be better. What you say on this?
Prithvi Sehgal
Ranch Hand

Joined: Oct 13, 2009
Posts: 774
Hi,
I suggested it before We can follow like this for next ten days.

- Strategy Pattern
- Decorator Pattern
- State Pattern

All three of them are interconnected and it is a course outline for 2 weeks. What do you suggest?

BR,
Piyush Joshi
Ranch Hand

Joined: Jun 10, 2011
Posts: 207

Sounds great! I second that.
James Boswell
Bartender

Joined: Nov 09, 2011
Posts: 1030
    
    5

Hey guys

Count me in on this one. I think it could be very useful for people like myself who have skim read the HF Design Patterns book.

However, I do feel that patterns are there as solely a guide and a label to producing better software. There is nothing like practice (writing bad code and learning from your mistakes) to better understand design patterns.

Piyush Joshi
Ranch Hand

Joined: Jun 10, 2011
Posts: 207

I think learning a design pattern is not difficult; but when and to what extent you should use it and when to avoid it, comes by experience. There may be situations where not using a pattern is better for simplicity.
Also a novice developer like me will try to over-use as many design patterns as possible in his design but will fail to recognize that many a times using a pattern is unnecessary.
So IMO there is learning from mistakes in using design patterns also.
Prithvi Sehgal
Ranch Hand

Joined: Oct 13, 2009
Posts: 774
Hi,

I agree with Piyush completely, learning by mistake concept is everywhere.Anyhow lets drop this discussion and ready Strategy pattern
today, because we have to discuss and implement it during this week. I will read it in another 3-4 hours and get back.

BR,
Yogesh Gnanapraksam
Ranch Hand

Joined: Dec 17, 2009
Posts: 133
Also we should understand how these patters are classified..
Prithvi Sehgal
Ranch Hand

Joined: Oct 13, 2009
Posts: 774
hi,
What's the status guys? Has anyone completed Strategy pattern reading?
BR,
Piyush Joshi
Ranch Hand

Joined: Jun 10, 2011
Posts: 207

hi Prithvi,
I finished strategy pattern 2 days ago, but couldn't get time to post here.
Seems like you guys also finished reading it (or not! ??).

So I think we should start the discussion.

In my opinion some important points about strategy pattern are:
- It directly emphasizes these design principles:
1. Encapsulate what varies: makes it easier to change the code when those requirements changes.
2. Program to interface not to implementation: results in loose coupling and thus we can change the implementation without changing the rest of the code.
3. Favor Composition over Inheritance.

If we think with respect to the Duck simulator example given in the HeadFirst book, we can see that it was the fly and quack behavior which was changing among the Duck classes. So we can encapsulate these in separate behavior implementation classes.
Then next we can favor composition over inheritance and instead of inheriting the fly and quack behavior from Duck superclass we can have Fly and Quack behaviors as instance variables in Duck class and performFly() and performQuack() methods delegate to these instance variables.
Also since type of these instance variables is a respective behavior interface implemented by the concrete flyBehaviors and quackBehaviors we can change a behavior at runtime using polymorphism.

I think now it will be worthwhile to point out the definition of this pattern:

"Define a family of algorithms, encapsulate each one, and make them interchangeable.
Strategy lets the algorithm vary independently from clients that use it."
Yogesh Gnanapraksam
Ranch Hand

Joined: Dec 17, 2009
Posts: 133
I just thought of a an situation in life where strategy pattern is used...


Inherited behavior from parent to children is fixed ,it cannot modified and it becomes part of the gene...

Strategy pattern is like adapting to different behaviors when acquainting ourselves with different friends ....
If you want to party you join some friends who share that behavior ....(composition )...
if you want to go adventure trips...u compose with friends with who provide you that company and experience..

So it all depends on what you need and you compose with different people accordingly...

Thanks
Yogesh.
Piyush Joshi
Ranch Hand

Joined: Jun 10, 2011
Posts: 207

Hi Yogesh,
Can you please elaborate this example.

I don't see in this scenario how interchangeability of behaviors can be implemented. You call a party loving friend when you want to party, and gang up with your adventurous friends when you want to go for a trip. Here your needs or scenarios are different, one is party and second is adventure trip. But if you consider one particular scenario then you can not interchange a party loving friend with adventurous friend.
Yogesh Gnanapraksam
Ranch Hand

Joined: Dec 17, 2009
Posts: 133
It depends on the need..composition happens at runtime...
You will not know which algorithm you are going to use ,it is a runtime behavior (based on the mood ) ..

When in party mood, at run time the class that implements the party interface is instantiated and that instance is composed with the class that needs to implement this strategy.

I will come up with a simple class diagram shortly.

Regards
Yogesh.

Prithvi Sehgal
Ranch Hand

Joined: Oct 13, 2009
Posts: 774
Hi Guys,
Sorry to wake up the old daemon. Any one interested in carrying forward this exercise?
BR,
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Design Patterns Study Group