• 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...

 
Ranch Hand
Posts: 300
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi all,

I have just started to study Desgin Patterns. I am using Head First by K&B.
I am at Factory design pattern.

My problem is , i am confused with the decorator and factory.someone said me to identify the pattern for a flow , and i got confused with decorator and factory.


can someone help me to idenfity whether it has decorator or factory pattern.
cause i read somewhere factory pattern says -Define an interface for creating an object, but let the subclasses decide which class to instantiate. The Factory method lets a class defer instantiation to subclasses
but my understanding says it is decorator.
Also please tell me is there a good tutorial that can help in better understanding of design pattern
it is looking i could never understand the design pattern

Please help....
 
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I don't really understand the code you posted - it seems to be a form of pseudo code I'm not used to - but from the little I understand, I couldn't see any of the GoF patterns in it at all, let alone Decorator or Abstract Factory.

The Head First book is supposed to be quite good. You might want to take a look at the "Design Patterns Java Workbook" as a companion book, though.
 
Patricia Samuel
Ranch Hand
Posts: 300
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
yes, it is just a design of the flow not the code itself

interface

class1 implements interface
class2 implements interface

class3{

interface i = new class1();
}

i just want to know what design principles and pattern it is using
 
Bartender
Posts: 2968
6
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Right now the only attempt seems to be to program to an interface, not an implementation - which is immediately ruined by creating a concrete implementation inside the class.

Ideally Class3 should look like:



Now Class3 only depends on Interface1, not the concrete Class1 implementation of Interface1.
 
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
And the technique Peer used is called Dependency Injection. Often you will do this to comply to the Dependency Inversion Principle. Google for those terms to learn more about them.

No Design Pattern involved, though.
 
Patricia Samuel
Ranch Hand
Posts: 300
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi all,

Thanks for your replies.

But i think it does have "Startegy Pattern"


Thanks
 
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Can you please tell more about what you are trying to achieve? The purpose of Factory, Decorator and Strategy are different. The use of interfaces alone does not make a Factory, Decorator or Strategy and they belong to different genre.

Factory: Creates an instance of several families of classes. [A Creational Pattern]

Decorator: Add responsibilities to objects dynamically [Structural Pattern]

Strategy: Encapsulates an algorithm inside a class. [Behavioral Pattern]

Check this online resource out, its quite simple and friendly: http://sourcemaking.com/design_patterns

Characteristics of Decorator:

The Decorator Pattern is used to extend the functionality of an object dynamically without having to change the original class source or using inheritance. This is accomplished by creating an object wrapper referred to as a Decorator around the actual object. That ways decorator is an alternative to using inheritance.

  • The Decorator object is designed to have the same interface as the

  • underlying object. This allows a client object to interact with the Decorator
    object in exactly the same manner as it would with the underlying
    actual object.
  • The Decorator object contains a reference to the actual object.
  • The Decorator object receives all requests (calls) from a client. It in turn forwards these calls to the underlying object
  • The Decorator object adds some additional functionality before or after

  • forwarding requests to the underlying object. This ensures that the additional functionality can be added to a given object externally at runtime without modifying its structure.

    Strategy Pattern

    The Strategy pattern is useful when there is a set of related algorithms and a client object needs to be able to dynamically pick and choose an algorithm from this set that suits its current need.

    Well...!!! I guess this short introduction will probably help you a little. From your code it seems you have something related to dynamic behavior. Just be sure what you are trying to achieve and often Design Patterns are used in conjunction to each other.


    [ May 01, 2008: Message edited by: Arnav Mitra ]
     
    Patricia Samuel
    Ranch Hand
    Posts: 300
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    Arnav,

    Thanks for the link.

    Yes it seems to be startegy pattern as class will have different alogrithm and it will be decided dynamically.

    I have just started to learn design patterns. it might be i have asked dumb questions. I feel sorry for that

    Have a nice day!!!
     
    Arnav Mitra
    Greenhorn
    Posts: 5
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    Oh it was not at all a dumb question. "No questions are dumb" that's what K&B's Head First says right?


    Cheers,

    Arnav.
     
    Patricia Samuel
    Ranch Hand
    Posts: 300
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    Right!!!


    Cheers
     
    Peer Reynders
    Bartender
    Posts: 2968
    6
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator

    Originally posted by Patricia Samuel:
    I have just started to study Desgin Patterns. I am using Head First by K&B.



    Actually Head First Design Patterns is by Eric Freeman and Elisabeth Freeman with Kathy Sierra and Bert Bates.

    Yes it seems to be startegy pattern as class will have different alogrithm and it will be decided dynamically.



    In your initial example nothing is decided dynamically. The class1 (not a class2) instance is "created" regardless. Also no result is ever captured from the execution of "i.method()" so its unlikely that "method()" actually represents an algorithm. So for all we know class1 is a actually an implementation of the Command Pattern with an oddly named "execute()" method.

    Which brings up an important point. Design Patterns are recurring solutions to similar problems. In this case we have no idea what problem is that is being solved - design patterns only make sense in the context of the problem that they are solving.

    So effective use of Design Patterns requires that you can clearly discern the problem that you are trying to solve. If the problem belongs to a set of similar problems that are addressed by a particular pattern then that pattern may help you.

    GoF established a standard pattern template:
  • Pattern Name and Classification - The pattern's name conveys the essence of the pattern succinctly. A good name is vital, because it will become part of your design vocabulary.
  • Intent - A short statement that answers the following questions: What does the design pattern do? What is its rationale and intent? What particular design issue or problem does it address?
  • Also Known As - Other well-known names for the pattern, if any.
  • Motivation - A scenario that illustrates a design problem and how the class and object structures in the pattern solve the problem.
  • Applicability - What are the situations in which the design pattern can be applied? What are examples of poor designs that the pattern can address? How can you recognize these situations?
  • Structure - A graphical representation of the classes in the pattern.
  • Participants - The classes and/or objects participating in the design pattern and their responsibilities.
  • Collaborations - How the participants collaborate to carry out their responsibilities.
  • Consequences - How does the pattern support its objectives? What are the trade-offs and results of using the pattern? What aspect of system structure does it let you vary independently?
  • Implementation - What pitfalls, hints, or techniques should you be aware of when implementing the pattern? Are there language-specific issues?
  • Sample Code - Code fragments that illustrate how you might implement the pattern.
  • Known Uses - Examples of the pattern found in real systems.
  • Related Patterns - What design patterns are closely related to this one? What are the important differences? With which other patterns should this one be used?


  • The problem that you are trying to solve should be at least in part addressed by the pattern's Intent.
    Examples:
  • Strategy: Define a family of algorithms, encapsulate each one, and make them interchangeable. Strategy lets the algorithm vary independently from clients that use it.
  • Decorator: Attach additional responsibilities to an object dynamically. Decorators provide a flexible alternative to subclassing for extending functionality.
  • Command: Encapsulate a request as an object, thereby letting you parameterize clients with different requests, queue or log requests, and support undoable operations
  • Factory Method: Define an interface for creating an object, but let subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses.
  • Abstract Factory: Provide an interface for creating families of related or dependent objects without specifying their concrete classes.


  • If the Intent sounds like a possible solution to your problem then the Motivation will usually raise issues that are similar to the problems that you are facing. Applicability should reinforce that the pattern is in fact a suitable solution to your problem - at the same time it may raise issues that prevent you from using the pattern in your particular situation. Structure lays out the scope of the pattern and identifies the Participants. Each participant has its own responsibility and collaborates with other participants to complete the mechanics of the pattern. To solve your particular problem some particpants will have to be created from scratch while others may already exist in your system. The Consequences of using the pattern describes what further constraints may be placed on your system through the use of the pattern - some consequences may prevent you from using the pattern in your system. Related Patterns may identify patterns that are more suited to your particular problem.

    In the end there may not be a pattern to solve your particular problem.

    Also trying to identify patterns from "code" without a problem context isn't a suitable way to learn the effective use of design patterns - every OO language implements OO patterns slightly differently, each according to their own features and capabilities (some don't even need some of them). Design patterns are implemented in code but they are more abstract than code.

    There is a finite number of identified patterns while there are infinite variations of problems which means that not all the problems can be addressed by a pattern - in fact for majority of interesting problems there isn't a pattern. Fortunately there are Object-Oriented Design Principles that can also be applied in infinite variations.

    HFDP p. 31

    Guru: There are some object-oriented principles that underlie patterns, and knowing these will help you to cope when you can't find a pattern that matches your problem.


    The Object-Oriented Principles/Practices discussed in HFDP are
  • Commonality-Variability Analysis: Identify the aspects that vary and separate them from what stays the same (p. 9)
  • Program to an interface, not an implementation (p. 11)
  • Favor composition over inheritance (p. 23)
  • "Strive for loosely coupled design between objects that interact" (p.53) / Principle of Least Knowledge (p.265)
  • Open-Closed Principle (p.86)
  • Dependency Inversion Principle (p.139)
  • "Don't call us, we'll call you" (p.296) which usually results in the use of Dependency Injection.
  • Single Responsibility Principle (p.337)


  • The patterns discussions in HFDP are primarily case studies of recurring solutions to similar problems that were arrived at through skillfull application of Object-Oriented Principles and Practices! By mastering the Object-Oriented Principles and Practices you will not only have an easier time with Design Patterns but you will also be better equipped to face all sorts of other design challenges. Design Patterns only exist so that you don't have to "re-invent the wheel" every time you solve a similar problem. The "Object-Oriented Principles and Practices" should always be your first tool of choice - patterns only come into play once you realize that there is something "familiar" about the problem (because of the Intent, Motivation, and Applicability sections of the patterns that you have studied). In addition pattern names can make communicating with your peers more effective as everybody should know what you are talking about when you mention, for example, "Strategy" - it shouldn't be necessary to discuss the nitty-gritty details of the Strategy as it is a well documented pattern.

    Apply Patterns Gently
    Agile Software Development: Principles, Patterns, and Practices is a good resource in case you want to learn more about Object-Oriented Principles and Practices.
    [ May 01, 2008: Message edited by: Peer Reynders ]
     
    Patricia Samuel
    Ranch Hand
    Posts: 300
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    Thanks Peer!!
     
    Story like this gets better after being told a few times. Or maybe it's just a tiny ad:
    a bit of art, as a gift, that will fit in a stocking
    https://gardener-gift.com
    reply
      Bookmark Topic Watch Topic
    • New Topic