Menu
I have trouble understanding these two design patterns.
Can you please give me contextual information or an example so I can get a clear idea and be able to map the difference between the two of them.
Thanks.
617
The factory pattern is a creational pattern while the strategy is a behavioral pattern which means they were created using different approaches. We can solve problems in real life using both approaches but before using them we can check which approach is simpler and more effective to solve our problem.
The strategy pattern allows you to change the implementation of something used at runtime. The decorator pattern allows you augment (or add to) existing functionality with additional functionality at run time.
While the Strategy pattern is meant for behavior, the Bridge pattern is meant for structure. The coupling between the context and the strategies is tighter than the coupling between the abstraction and the implementation in the Bridge pattern.
A Visitor pattern lives at a different level. It details a mechanism with which objects can accept a reference to another object (the visitor) which exposes a predetermined interface that the target object can call upon itself. Of course, different visitors would present the same interface but have different implementations.
In the Strategy pattern, the Context behavior changes once by injecting a specific strategy and remains unchanged for the rest of its lifespan. Conversely, in the State pattern, the Context behavior can be changed dynamically during the rest of its lifespan by switching between its States.
Strategy and Visitor are unrelated. A Visitor is a strategy but with multiple methods and it allows Double dispatch. The Visitor also allows for safe binding between two concrete objects at runtime. Note: This is an example written in Java. For example C# introduced the dynamic keyword, therefor the example of double dispatch is not useful in C#.
Like Strategy, if your Context object has many if...else statements, this might be an indicator to use the State pattern. The Template pattern defines the skeleton of an algorithm in the superclass and overrides specific steps of this algorithm by its subclasses without changing its structure.
The strategy pattern is like a 1:many relationship. When there is one type of object and I want to apply multiple operations to it, I use the strategy pattern. For example, if I have a Video class that encapsulates a video clip, I might want to compress it in different ways. So I create a bunch of strategy classes:
MpegCompression AviCompression QuickTimeCompression and so on.
I think of the visitor pattern as a many:many relationship. Let's say my application grows to to include not just video, but audio clips as well. If I stick with the strategy pattern, I have to duplicate my compression classes-- one for video and one for audio:
MpegVideoCompression MpegAudioCompression and so on...
If I switch to the visitor pattern, I do not have to duplicate the strategy classes. I achieve my goal by adding methods:
MpegCompressionVisitor::compressVideo(Video object) MpegCompressionVisitor::compressAudio(Audio object) [UPDATE: with Java] I used the visitor pattern in a Java app. It came out a little different than described above. Here is a Java version for this example.
// Visitor interface interface Compressor { // Visitor methods void compress(Video object); void compress(Audio object); } // Visitor implementation class MpegCompressor implements Compressor { public void compress(Video object) { // ... } public void compress(Audio object) { // ... } } And now the interface and class to be visited:
interface Compressible { void accept(Compressor compressor); } class Video implements Compressible { // If the Compressor is an instance of MpegCompressionVisitor, // the system prints "Mpeg video compression" void accept(Compressor compressor) { compressor.compress(this); } A Strategy pattern is used to expose various algorithms to a standardized interface. A typical example could be a sort utility that would let the user (programmer) choose between various sort algorithms each called via the same interface.
A Visitor pattern lives at a different level. It details a mechanism with which objects can accept a reference to another object (the visitor) which exposes a predetermined interface that the target object can call upon itself. Of course, different visitors would present the same interface but have different implementations.
Coming back to our example, a collection of sort algorithms could be implemented either via the Strategy pattern or via the Visitor pattern.
With the Strategy method, each algorithm presents the same interface and takes arrays of target objects as parameters for example. With the Visitor pattern, it would be the target array that takes the "visiting" algorithm as a parameter. In this case, the target would "accept()" the selected visitor and call its "visit()" method upon invocation of the target's sort method in our example.
Two sides of the same coin...
Does this make sense?
35
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
