Win a copy of Functional Reactive Programming this week in the Other Languages forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Design Patterns for Beginners (Singleton/Factory/Observer)

 
phil hunter
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,

I thought I would get your expert advice on this subject as I dont know much about it. I would say I am an average programmer who is able at coding. I have written many programs such as applications and games. I am looking to step up my game by actually using design patterns in the design of my games and applications. What are the most popular common Design Patterns that are used by most programmers in the industry? I researched Singleton, Observer and Factory Design Patterns as I heard these where most popular, are they any others I should be looking at as a start into the world of Design Patterns?

For example, I created pacman and space invaders game, and also a BlackJack game. What design patterns should I have used for these? (Factory for first 2, Singleton for the last)


Any thoughts would be much appreciated.
 
Arvind Choudhary
Greenhorn
Posts: 15
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Please elaborate your requirement basis which a proper Design Pattern can be applied or suggested. For example if the requirement is seperating Database logic from bussiness layer
is a requirement then DAO pattern can be applied. Another example is when loading a large image(which is time consuming), you may create some light object to represent it until the image is loaded completely using Proxy pattern etc.
 
Winston Gutkowski
Bartender
Pie
Posts: 10527
64
Eclipse IDE Hibernate Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
phil hunter wrote:For example, I created pacman and space invaders game, and also a BlackJack game. What design patterns should I have used for these? (Factory for first 2, Singleton for the last)

Simple answer: the correct ones - and without knowing precisely what you want to do, nobody can answer your question.

Patterns are not like algorithms (eg, Quicksort), where there is a probable "best" application; they are more like a toolbox.
Before you make a table, you first need to know the basics of carpentry, and to do the job you need tools. You don't use a chisel to cut a leg to the correct length, you use a saw.

And it's a bit like that with using Patterns: you use the one that is applicable. And before (long before) you make that choice, you must understand precisely what it is you want to do. Furthermore, you should be able to justify your reasons for using a particular pattern.

The only thing I can tell you is that if you think you need a Singleton, have a look at using an enum first. I believe Erich Gamma has said more than once that if he'd had a second chance to write the grandaddy of design pattern books, he would have left out Singleton.

Winston
 
phil hunter
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Dont forget, Im just new to Design Patterns. Just looking some basic guidelines and some common design patterns to study up on..
 
Winston Gutkowski
Bartender
Pie
Posts: 10527
64
Eclipse IDE Hibernate Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
phil hunter wrote:Dont forget, Im just new to Design Patterns. Just looking some basic guidelines and some common design patterns to study up on..

Well, the book I linked is probably a good start.

And I hate to say, but this is not the sort of stuff you can simply "dive into". Understanding how and when to use design patterns requires familiarity, both with the patterns themselves and what you're trying to do.

Patterns are based on even more basic premises like loose coupling and, in my experience, the times that I've found them most useful is when I have what I call a "Hmmm" moment - usually because I'm doing something fairly major for the second time - because then, not only do I realise that there might be a pattern I can use, I'm in a mindset where I'm ready to accept it.

In the meantime, by all means read up on them, but don't be looking for a pattern in everything you do. Just write good, clean code, and analyse every problem before you write any code.

If you're smart (and it sounds like you are) the patterns will present themselves (or you'll become better at spotting them ).

Winston
 
Junilu Lacar
Bartender
Pie
Posts: 7766
62
Android Eclipse IDE IntelliJ IDE Java Linux Mac Scala Spring Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I like Joshua Kerievski's "Refactoring to Patterns" book, it basically recommends the approach to patterns that Winston describes. Don't start with the pattern but rather start with clean code and try to see if the problem you are trying to solve is the same kind of problem to which a known design pattern can be applied. If it is, you can start refactoring your code towards the pattern.
 
phil hunter
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Ok, thank you for all your replies. From your posts, I will summarize below:

1) There are no generic or common patterns to use, it depends on what are you are trying to do.
2) Design Patterns come with experience and you should ask yourself has this problem been solved before with a Design Pattern.
3) You can write good clean code and then include the Design Pattern when you are refactoring.



Good sources of info:
Joshua Kerievski's "Refactoring to Patterns"
http://www.javaranch.com/patterns/
 
Winston Gutkowski
Bartender
Pie
Posts: 10527
64
Eclipse IDE Hibernate Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
phil hunter wrote:1) There are no generic or common patterns to use, it depends on what are you are trying to do.

Not quite. Patterns work specifically because they are generic.
Indeed, many of them are based on the old chestnut that "all problems in computer science can be solved by another level of indirection".
However, which one is applicable will certainly depend on what you're doing.

2) Design Patterns come with experience and you should ask yourself has this problem been solved before with a Design Pattern.
3) You can write good clean code and then include the Design Pattern when you are refactoring.

Pretty much, but the experience comes in (hopefully) spotting them before you need to refactor.

Winston
 
Junilu Lacar
Bartender
Pie
Posts: 7766
62
Android Eclipse IDE IntelliJ IDE Java Linux Mac Scala Spring Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Winston Gutkowski wrote:
Pretty much, but the experience comes in (hopefully) spotting them before you need to refactor.

I almost always need to refactor my code

Maybe it's because I've gotten so used to the TDD cycle (write a test, make it pass, make it clean) that I don't worry too much about writing clean code until I'm in the refactor step. I firmly believe that writing less than perfect code really helps you get the experience needed to spot where patterns and idioms can be applied, as long as you always spend time to read and refactor your code as soon as it passes its tests. You have to know what you did poorly in order to recognize that you're doing better.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic