• 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

NOT thinking about patterns

 
Ranch Hand
Posts: 379
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Over the last few months, I feel that the patterns have been over-emphasized everywhere. While I am a strong supporter of patterns, I can't help getting the feeling that people are thinking about patterns when they shouldn't be.

So, here's the question.

What would be a good approach towards thinking about patterns? More importantly, during what stages in software development, should one NOT be thinking which pattern to apply?

For starters, I would think that one should be more concerned about applying patterns after writing some basic code than before (more like refactoring to patterns).

Comments?
 
ranger
Posts: 17347
11
Mac IntelliJ IDE Spring
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Well, in Analysis and higher level design you might not be thinking about patterns. But in detailed design, and in architectural design you will most likely want to make sure you are thinking about patterns.

Sometimes a pattern might not appear till after you start writing some code and find that you are repeating code, etc.

Patterns can never be over-emphasized, it really helps write better code, especially for making readible and maintainable code, which should be the number one thought in every coders mind when developing.

The real problem is knowing just one pattern, and using it to solve all your problems.

Mark
 
Author
Posts: 39
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Personally I do think it is possible to over emphasize patterns - I've seen too many systems where the quality was judged by quantity of patterns. In my experience people often get fascinated with one or two patterns and use them over and over regardless of the actual problem it solves.

While I do think one should consider patterns while designing I think refactoring to patterns is much more likely to result in a better system. So many of the patterns exist to isolate the things that change from those that don't and sometimes we just don't know what is going to change until we start to use the system.

As an example, my company uses a proprietary Java framework (don't ask me why) and it has a logging API (which used to wrap jlog, now its proprietary!) Originally my app wrote directly against the framework's logger but after it was completely changed (again, don't ask why) I decided to wrap their logger in an API that I could control. I suppose I could have done this at the outset but I didn't see the need until after I got whacked in the head - so should I have wrapped the logger on the change it would change or wait until it did?

To paraphrase Dennis Miller: but that's just my opinion, I could be wrong!

Nate
 
Ranch Hand
Posts: 872
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
When I am creating a application, I stick to the core values I believe most applications need I believe they have higher precedence then anything else.
1.Small object methods or functions
2.Resuable utility/helper functions
3.Good namespace management
4.Data hiding of 3-party librarys away from the rest of the application. A simple fa�ade implemented as a function.

I don't see any reason to use any fancy object oriented technology, it only complicates things and compromises my core values which I am very familiar with. Object oriented technology is perfect for creating librarys and GUI toolkits but linking them together into an application simple procedural programming using a high level scripting language like perl, python or VB, sweet!
 
High Plains Drifter
Posts: 7289
Netbeans IDE VI Editor
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The Golden Hammer has many names, takes many forms, speaks in many tongues. Constant vigilance is your only defense.
 
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I often do *think* about patterns early - such as in "this task sounds hard at first sight, but using the Abstract Factory pattern at that place should make it possible to implement it in a day."

I don't *commit* to patterns though. Early design ideas are just that - ideas. They need feedback from coding them to get refined, and it isn't really unusual to find out that a different pattern is a better fit, or even that a fully fledged pattern would be overkill anyway!
 
Ranch Hand
Posts: 385
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I'd take "what I have to do to make it simple and working" approach and definitely not "i have to use pattern. but which and where". I'd learn patterns and sometimes I will spot the right moment to use them.

I think it's wrong to take a problem and try to fit it into some pattern. Problem is above all, solving it matters most. To solve it I have to use right pattern or not use any at all.
 
Ranch Hand
Posts: 3271
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I'm no Extreme Programming expert (in fact, I know little about the concept), but one of the main ideas of XP is to simply start programming, right? As you build, you constantly refactor. In such a case, I don't think you'd necessarily "plan" to use a pattern - you'd be coding something and simply realize, "Gee, this would be a lot cleaner if I'd use a factory pattern." At that point, you'd refactor your code to a factory pattern.

Such a scenario shows that patterns can be used without planning for them from the beginning. In my opinion, patterns shouldn't be used for the sake of using patterns, but they can be very useful in terms of making quality software.
 
Ranch Hand
Posts: 94
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Sathya Srinivasan:

What would be a good approach towards thinking about patterns? More importantly, during what stages in software development, should one NOT be thinking which pattern to apply?



I think this is a continuous process. Starts with architecture and goes down to life of software.


For starters, I would think that one should be more concerned about applying patterns after writing some basic code than before (more like refactoring to patterns).



Don't we all do that though!!! Atleast people who are following TDD. Isn't it true that while you are writing your unit test you realize that there are too many ifs and cases you might want to use certain pattern here?
 
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

Originally posted by Corey McGlone:
I'm no Extreme Programming expert (in fact, I know little about the concept), but one of the main ideas of XP is to simply start programming, right?



Well, not exactly. You first need to estimate your Stories, which often involves having at least a very rough idea of a possible design solution. You often also do a short design session (say, ten minutes) before you start TDDing.

You are right in spirit, though - we don't *commit* to the use of a pattern before the code actually calls for it.
 
Anderson gave himself the promotion. So I gave myself this tiny ad:
a bit of art, as a gift, the permaculture playing cards
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic