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.
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.
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.