• Post Reply Bookmark Topic Watch Topic
  • New Topic

Head first strategy pattern question  RSS feed

 
Bob Zoloman
Ranch Hand
Posts: 72
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi, I recently purchased the Head First Design pattern book, and I was going over the strategy pattern, which made sense when I read it, but I'm having trouble applying it to one of my own projects.

The part that gets me is when you remove behaviour that varies from a super type class into their own classes. Say I remove class A, and B from a supertype class and make them interfaces, and each implementation is supposed to implement one of those interfaces. The problem I usually have is that the method signature usually changes from implementation to implementation, but it has to be like it is in the interface. I'm not sure how to encapsulate the behaviour that changes if the method signatures change between implementations. Any help is appreciated, thanks.
 
Ernest Friedman-Hill
author and iconoclast
Sheriff
Posts: 24217
38
Chrome Eclipse IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Call your supertype class S, your strategy interface I, and the first implementation of I, call it A. Then by definition, I can always look like



since any code in used to be part of S, so anything A needs, S has. It's often the case that you don't have to pass all of S, but let's assume that's what you're going to do.

Now, in general, if B is another implementation of I, you're saying that B is going to need other arguments than S. I say no, that's not true. It is possible that different implementations need different data, but those different implementations don't have to have the same constructor arguments, right? You can pass various other information in when the strategy implementations are constructed, and that stuff can be stored in member variables. Then in the implementation of doSomething(), the incoming S can be combined with the preexisting information, and Boom! You're all set.
 
Bob Zoloman
Ranch Hand
Posts: 72
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
So what your saying is I can pass a reference of the superType in my method arguement instead of a String, int or some other datatype, so I can always use the same method signature? In your example is the method returning an object or a primitive dataType?
 
Christophe Verré
Sheriff
Posts: 14691
16
Eclipse IDE Ubuntu VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Depending on your needs, it can returns a primitive, or any data type.
 
Ernest Friedman-Hill
author and iconoclast
Sheriff
Posts: 24217
38
Chrome Eclipse IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Bob Zoloman:
So what your saying is I can pass a reference of the superType in my method arguement instead of a String, int or some other datatype, so I can always use the same method signature? In your example is the method returning an object or a primitive dataType?


Yes, the argument list can be anything. If different strategies will need different things from the "host object", then it would make sense for the host object itself to be an argument.

In my example, "X" is whatever you want it to be -- whatever is appropriate to the problem.
 
Bob Zoloman
Ranch Hand
Posts: 72
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Sounds good i'll give it a try. Thanks for the help!
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
There might also be other solutions, but it's rather hard to discuss those in the abstract. It might help if you'd show us a concrete example.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!