• 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

xp and the big picture

 
Ranch Hand
Posts: 1282
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
not sure if this is the right place, but here i go
i'm a java enthusiast (no pro, just for the fun of it) and i try to read
about good programing focus like patterns; on the other hand, though i'm alone, xp is a world that seduces me.
I've been told that one should apply patterns because that way code gets better prepared for future (inevitable) change; on the other hand, xp uses very small steps aproach: red, green, refactor.
My doubt: how come xp and using patterns doesnt conflict? how can someone write some simple method, test it, and so on (xp way) and at the same time be sure patterns are beeing considered/implemented?

Hope i made myself clear enough...
 
author
Posts: 11962
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by miguel lisboa:
how come xp and using patterns doesnt conflict? how can someone write some simple method, test it, and so on (xp way) and at the same time be sure patterns are beeing considered/implemented?


Two things:

Even though XP promotes a practice of Simple Design (renamed to Evolutionary Design in the 2nd edition of Kent Beck's "Extreme Programming Explained") and people go around repeating acronyms like YAGNI, that doesn't mean that XP would somehow discourage the use of design patterns. Once you've gotten from red (failing test) to green (passing test), it's time to refactor and that may or may not include applying a design pattern to your code. In fact, the practice of refactoring constantly drives you towards a sensible use of design patterns.

It's not a coincidence that the same people who were instrumental in bringing design patterns to mainstream are today instrumental in bringing extreme programming to(wards) mainstream.
 
miguel lisboa
Ranch Hand
Posts: 1282
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

It's not a coincidence that the same people who were instrumental in bringing design patterns to mainstream are today instrumental in bringing extreme programming to(wards) mainstream


yes, i'm thinking in Martin Fowler, for one example.
Maybe after all i got the (wrong)idea xp doesnt stop to think (about 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
When people first discover patterns they are tempted to realize "I could use pattern x here!", go to the book, copy out the design, write a full blown implementation with every class, method, variation, contingency, etc. When the book came out I knew some people who rushed out to do just that for every pattern in the book so they'd have a library to use. Either approach is an educational exercise I'm sure, but it's also a lot of code that's never used again.

If I start to recognize one of the GoF patterns in my code I might go to the book to look for well-known class names, gotchas or better ideas. But I still like evolutionary design and build the least possible stuff to do the job.
 
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
In short, when during the refactoring step of TDD it looks like applying a pattern might simplify the code, you start refactoring into the direction of that pattern.

There are two very good books out there discussing this topic in detail:

"Agile Software Development - Principles, Patterns and Practices" discusses the basic OO design principles that lead to good, well factored code, and how some of the design patterns help to comply to those principles. https://coderanch.com/t/93457/Book-Reviews/Agile-Software-Development-Principles-Patterns

"Refactoring to Patterns" is solely about, well, how you refactor to, towards and even away from patterns. https://coderanch.com/t/93702/Book-Reviews/Refactoring-Patterns-Joshua-Kerievsky
 
blacksmith
Posts: 1332
2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
In most cases, the patterns that are useful are the ones that are simpler than alternative implementations. Using patterns shouldn't be any different from any other coding.
 
miguel lisboa
Ranch Hand
Posts: 1282
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

In most cases, the patterns that are useful are the ones that are simpler than alternative implementations.

i dare say patterns are welcome in view of changes in clients needs

Using patterns shouldn't be any different from any other coding.


well, for one thing its harder, since you'v to learn them in a way you can detect its presence in code
 
Warren Dew
blacksmith
Posts: 1332
2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
well, for one thing its harder, since you'v to learn them in a way you can detect its presence in code

Hm, to start off, here's a couple patterns almost everyone recognizes.

Assignment pattern:

y = x;

Delegation pattern:

object.callFunction(argument);

While those are so simple no one writes books about them, some of the ones in the books are not a lot more complex. It's probably best to start with those and understand where one might use them.

The typesafe enumeration is one good place to start, as almost everyone has written code that could benefit from it.
reply
    Bookmark Topic Watch Topic
  • New Topic