Can I implement Strategy Pattern using AOP. I would like to either
1. Override the default algorithm
2. Or Would like to dynamically select any of the given algorithm.
Thanks,
Look at "AspectJ Cookbook" by Russell Miles. It provides implementation of almost all classical design patterns from the point of AspectJ's view. Here is direct link to strategy pattern http://books.google.com/books?id=AKuBlJGl7iUC&lpg=PP1&pg=PA230#v=onepage&q&f=true.
Related
My API has different parameters. Depending on those, I have two slightly different processes. But output almost same. Should I use builders pattern ?
For example, suppose there are different query parameters A and B:
// For case A:
if (A){
funX(A);
funY();
funZ();
}
// For case B :
if(B){
funW(B);
funX(B);
funY();
funZ();
}
Note : here process is little bit complex. Such as Third party api call, filter, sorting, complex calculation and so on.
The simple fact of having slightly different processes does not justify nor call for a builder pattern.
Unfortunately, your question doesn't show anything about your object structure, so it's difficult to advise how to implement it. Typically, here some examples:
polymorphism: different classes implement the behavior promised in their base class a little bit differently. Depending on your parameters, you would instantiate the right class.
template method is a particular use of polymorphism, where the core structure of the process is implemented in the base class, and make use of auxiliary functions that are implemented slightly differently.
composition: parts of the behavior are implemented in different classes/objecs. the process is can be assembled by composing the different parts. It is more flexible than inheritance.
strategy, decorator, command, chain of responsibility are all design patterns that use composition (sometimes in relation with inheritance), that could allow to implement the behavior slightly (or radically) differently. Plenty of other approaches use composition to achieve your goals.
Anyway, try not to use design patterns as a catalogue of basic ingredients to solve your problem. THe right way is the opposite: think of how you want to solve the problem, and then use design patterns if you see that they address some of your desing intentions.
To come back on the builder pattern: this is a pattern that is meant to construct complex classes, and apply a same construction process to different classes that follow a same logic for their construction. I don't see this kind of challenge in your code example.
I recently written a ValidationBundle, to validate the arguments passed to a method. Validation bundle accepts different types of Validator's. Upon validating the bundle, it invokes each one of the validators registered with the bundle. I was wondering if any pre-existing design pattern is followed or not?
Well, the Builder pattern is obviously used to construct the ValidatorBundle and the Iterator pattern is used to loop through it.
This isn't the typical Strategy implementation you would see in a tutorial, but assuming there is an abstract Validator which is implemented by DataTypeValidator, ArgLengthValidator, etc., then I think it's fair to label them as "a family of interchangeable algorithms," which qualifies as the Strategy pattern.
Going beyond design patterns, it would be interesting to see this implemented with a different paradigm. Specifically, I think this type of validation could be implemented as a cross-cutting concern with AOP.
In general, I know that there are 3 big types of design pattern
Creational Pattern (Factory, Singleton, etc)
Structural Pattern (Composite, Adapter, Proxy, etc)
Behavioral Pattern (Specification, Command, etc)
But I dont know which type I can put the Repository pattern in.
Is Repository pattern in one of three above type? Or is it kind of in the middle of (2) and (3) pattern?
Repository can be viewed as a special kind of Façade (structural) but also as a special kind of Factory (creational). Also, as the Repository often expose collection-like interface, then it might be a special application of Iterator (behavioral).
What I am trying to say is that neither those categories nor patterns themselves are any sort of definite doctrine. There are just some ideas and a language that tries to make them more explicitly visible. These categories are just helpers trying to express somehow what some patterns do. Also patterns are just various expressions of a generic loose coupling principles. Their borders are blurry.
A repository is a specialisation of the Facade pattern which is structural.
I assume you refer to the repository pattern by Martin Fowler.
He says:
Repository: Mediates between the domain and data mapping layers using a collection-like interface for accessing domain objects.
He himself categorizes the pattern as "Object-Relational Metadata Mapping".
If you want to use the categories in the GOF book, I'd put it into the structural pattern category as the focus of this pattern is to present an interface/view to a client, similar to the Adapter/Facade/Proxy patterns.
For some homework, we have to devise an example (with classes) where both the Strategy and Template Method design patterns come together to complement each other and make them more customizable as a result. Or "use template method to provide more customizability to handle a variety of strategies" as it says.
After much reading and initial confusion, I came up with the idea of having two animals as classes, Dog and Snake and have them both use interfaces to implement a specific function, moving (so a dog might walk and a snake would slither). I thought this to be the Strategy pattern portion, as they're each separately implementing their own move functionality.
In order to incorporate the Template Method pattern into this, I thought I'd make it so the class it's implementing is then subclassed further for customizability, which seems to go with the question. So I thought I'd have Mover as the class and have it subclassed down into Walk and Slither. But this confused me as would each animal implement the superclass Mover, or one of the subclasses? And is the superclass Abstract, while the subclasses are Interfaces? Or are they all interfaces?
Does my example make sense?
As Per my Understanding your example does't fit into the Strategy and Template, the Scenario best fits into Abstract Factory and May be Prototype (Depends upon full requirement).
The basic difference between strategy and Template is Inheritance v/s Delegation.
If you are Searching for Strategy and template Example i would suggest you to go with some game application where the Full game can fit into template function like end of game, start the game,Winner of the game looser of the game and the Rules to play the can be fitted into Strategy like when to move, what to do with some moves.
No. The main reason is because Strategy applies when you need to have different ways to do the same thing, e.g. a Layout Manager. In your example, Snakes have one way of moving, likewise Dog.
Frankly, I don't see those patterns as going together so well, not sure what the assignment is after. Template Method is great when things are done in a particular way, and variants merely implement steps of the process differently.
Probably you should think of a process where one of the steps could have a Strategy plugged in.
Your example is OK if you would somehow manage to get appropriate names to BeginMove and EndMove methods in MoverStrategy.
Here:
GetMoveStrategy - FactoryMethod responsible for declaring interface for creation appropriate strategy
MoverStrategy - Strategy
Move - Template method with one placeholder DoMove which Concrete Strategy must define
I'm working on the issue of design patterns. In this case I want to implement design pattern 'Facade'
I know that 'Cocoa Touch' offers us complete solutions for applying design patterns in our projects (for example NSNotificationCenter - implements observer design pattern)
My questions is next: - do we have ability to using design pattern 'Facade' as well as in the case of the observer design pattern.
Now I implement 'Facade' like this:
For example i have some classes which implements some calculations. The 'Facade' class combine all classes which I needed to calculations.
For example i have classes A, B, C and Facade (which contain A, B and C classes).
When I want to calculate something I just create my 'Facade' and pass some argument for calculation. In this case I don't know about classes A, B, C and this Facade object provides me one access point only.
This design pattern encapsulates objects and simplifies the application.
Is it correct implementation?
Another a good example for implementing facade pattern - pizza call service.
For example, pizza service (subsystem) is very large and it consists of three departments (interfaces) : order department, discount department, delivery department. Each departments has own logic and interfaces.
You can simply implement facade pattern on it.
Here this example in more details.
A Facade is defined as unified interface to a bunch of interfaces - sort of higher level interface to reduce the complexity. Instead of dealing with several classes and knowing the API's of each its reduced to the facade. Your explanation looks OK to me.
It is correct explanation (i don't see implementation). Nice association to Facade pattern in real life is remote control - you can run TV functions, DVD and so on.
The motivation behind the facade pattern is to provide a simplified interface for often-used cases, while accommodating the ability to reach past the simplified interface and interact with more complex aspects of the classes behind the facade when neccessary. As you've described your implementation, it would certainly seem to fit the description, and there is no reason you couldn't use a facade pattern in combination with a notification/observer pattern...