• 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 pattern is not for new guys?

 
Ranch Hand
Posts: 434
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I've lots of discussions with some expericned programmers these days. I think design pattern is a foundational skill for an OO programmer. Just like an OO programmer needs to master a language like Java. In my ordinary work, I've used more than 10 patterns introduced by GOF which quite help me a lot. So I recommend to our programmers. But I'm soon flooded by the condemnation.

1 You'd better make your programme structur more clearly.
But I think this is what design patterns do.

2 Please make sure the function is implemented correctly first.
But I think to implented correctly is the fisrt step, as a programmer I need to make the proramme more flexible and extendable. This is what patterns can do.

3 We are sick of some freshman to say patterns. And patterns are overemphasized.
But little of them have ever read books on design patterns and use them in their oridnary work.

What I do is just to persuade them to read books on patterns, try to use them in their work. But I become thire enemy . You should focus on algorithm, functions, business logical. Yes, I don't mean these are not important. But as an OO programmer, I think we should master some patterns to make our work better. So my question is:
What's the position of design patterns in the OO programming? How do you use them in your ordinary work? If someone can help me answer the criticism listed above is better.

Thanks.
 
Greenhorn
Posts: 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Guidelines are needed when Interfaces are designed for services.
I have many times asked from forums about Best Practices and Guidelines
how to implement (or at least try to implement) a working, easy to understand and "good looking" Interce layer for Services.

Never got an answer.

My opinion is that developers does not use Design Patterns only for reason they can tell other people that they have used Design Patterns.
There must be some advantage when Design Patterns are used.

I have also read books considering Patterns. There are many kind of implementations. Funniest and also the most stupid are those where e.g. Abstract Factory is a BirdFactory and Pelican is one of classes that it creates etc.

How wants to read this kind of stuff if you work as an software designer/programmer? No one.

So, some guidelines should also be available so that programmers would know
where and what kind of pattern would be best. And if pattern is not needed
somewhere then we should not use them.

Have a nice starting week!
[ August 28, 2006: Message edited by: John Billington Jr ]
 
author and cow tipper
Posts: 5009
1
Hibernate Spring Tomcat Server
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
One thing about design patterns is that they create a common vocabulary. This can't be understated as being important, especially with new developers on the team.

I mean, imagine having to tell a developer to create a class that only ever allows one instance to ever be created. It's nice to be able to say to someone "Just implement it as a singleton."

A common vocabulary is a huge leap forward on any development team.

And I don't think everyone should be so down on a BirdFactory. lol
 
Greenhorn
Posts: 14
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I'm also interested in "guide lines" not just plain design patterns.
I have also looked material considering this issue but not found.
Only good reference for using pattern, when you are starting to use them is
e.g. Jakarta's projects.
 
Bartender
Posts: 2968
6
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
See also: New Article: Evil Patterns
 
Qunfeng Wang
Ranch Hand
Posts: 434
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thank you all.

But I'm more confused now. You could know from my word that I'm a fans of Design Patterns(but still a fish to this field).Now you someone said we need these guidlines, someone said it may be eavil.How about my feeling? I use it and get the result I want. For example, a third party's device is added to our application,we can manage it because of our Factory Pattern, then we programm to the interface not the object.

 
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 Loius Wan:
But I'm more confused now. ... How about my feeling? I use it and get the result I want.



As referenced in the other thread from Apply Patterns Gently:


Apply Patterns Gently. Effective modelers learn and then appropriately apply common architectural, design and analysis patterns in their models. However, as Martin Fowler points out in Is Design Dead? developers should consider easing into the application of a pattern, to apply it gently. This reflects the value of simplicity. In other words, if you SUSPECT that a pattern applies you should model it in such a way as to implement the minimal amount you need today but that makes it easy to refactor it later when it is clear that applying the full-fledged pattern is in fact the simplest approach possible. In other words, don't over model. For example, you may recognize a good spot in your design to apply the GoF's Strategy pattern, but at the current moment you only have two algorithms to implement. The simplest approach might be to encapsulate each strategy in its own class and build an operation that chooses them appropriately and passes them the appropriate input. This is a partial implementation of Strategy that leaves you in a position to refactor your design if more algorithms need to be implemented, yet does not require you to build all the scaffolding that Strategy requires -- an approach that enables you to ease into application of the pattern.


i.e. don't pursue design patterns for their own sake, employ them only where they add value now - use design patterns judiciously.
 
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
In addition to what Peer said, you absolutely need to learn the design *principles* that drive the use of the patterns - the Open Closed Principle, Single Responsibility Principle etc. pp.

"Agile Software Development" by Robert C. Martin is a very good book on that topic.

Another interesting book is "Refactoring to Patterns".
 
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Apply Patterns Gently. Now you got me hummin Tenacious D songs. Waiting for the movie.
 
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 Ilja Preuss:
"Agile Software Development" by Robert C. Martin is a very good book on that topic.
Another interesting book is "Refactoring to Patterns".



Agile Software Development: Principles, Patterns, and Practices by Robert C. Martin (2002)
Amazon US
Object Mentor
Prentice Hall

If you don't mind an earlier version of some of the material in C++ have a look at: look here.
  • SRP: The Single Responsibility Principle
  • OCP: The Open-Closed Principle
  • LSP: The Liskov Substitution Principle
  • DIP: The Dependency Inversion Principle
  • ISP: The Interface Segregation Principle

  • (However the book is a significant update)

    There is now also an updated version
    Agile Principles, Patterns, and Practices in C# by Robert C. Martin, Micah Martin (2006)
    Amazon US
    Prentice Hall
    It also includes material from "UML for Java Programmers" only all in C# - the original book used mainly Java and some C++ (As stated here).

    This one is a bit more advanced:
    Refactoring to Patterns by Joshua Kerievsky (2004)
    Amazon US
    Addison-Wesley Professional
    Refactoring to Patterns Home Page
     
    Consider Paul's rocket mass heater.
    reply
      Bookmark Topic Watch Topic
    • New Topic