is this an example of TemplateMethod Pattern??
public abstract class Character{
public final void useWeapon(){
useBusterSword();
useMateriaBlade();
useUltimateWeapon();
}
public abstract void useBusterSword();
public abstract void useMateriaBlade();
public abstract void useUltimateWeapon();
}
public class Cloud extends Character{
public void useUltimateWeapon() {
System.out.println("Change Weapon to Ultima Weapon");
}
public void useBusterSword() {
}
public void useMateriaBlade() {
}
}
public class TestGame {
public static void main(String[] args){
Character cloud = new Cloud();
cloud.useWeapon();
}
}
If so then what is the advantage of using this pattern than strategy pattern??
Strategy Pattern
public class Character {
WeaponBehavior w;
public void setWeaponBehavior(WeaponBehavior wb){
w = wb;
}
public void useWeapon(){
w.useWeapon();
}
}
public class Cloud extends Character{
public Cloud(){
w = new UltimaWeapon();
}
}
public interface WeaponBehavior {
public void useWeapon();
}
public class UltimaWeapon implements WeaponBehavior {
public void useWeapon() {
System.out.println("Change Weapon to UltimaWeapon");
}
}
public class BusterSword implements WeaponBehavior {
public void useWeapon() {
System.out.println("Change Weapon to MateriaBlade");
}
}
public class MateriaBlade implements WeaponBehavior {
public void useWeapon() {
System.out.println("Change Weapon to MateriaBlade");
}
}
public class TestGame {
public static void main(String[] args){
Character c = new Cloud();
c.useWeapon();
}
}
What I noticed is Strategy pattern encapsulate what varies unlike TemplateMethod Pattern lets the subclassed handles what varies.
Strategy pattern defines a family of algorithms and makes them interchangeable. Client code can use different algorithms since the algorithms are encapsulated.
Template method defines the outline of an algorithm and lets subclasses part of the algorithm's implementation. So you can have different implementations of an algorithms steps but retain the algorithm's structure
So as you can see the intent is different in each pattern. So it is not a matter of advantage of one over the other.
Yes you can use strategy pattern instead of template method but in special case you will repeat algorithm logic.
The best use case for template method to replace some abstract method by specific implementation.
E.g. You want to cook smth and your recipe is:
take ingridients
put them into
heat
give coocked food to smbd
In java recipe is just method in some Recipe class
void cook(){
takeIngridients();
putIt(); // abstract
heat(); //abstract
giveFood();
}
You create PanRecipe class extends Recipe and implement abstract methods to use pan.
Another class can be GrillRecipe and implement methods to use grill. Now you can just call it by grillRecipe.cook(), and instead of strategy pattern don't need to copy implementation of repeated methods takeIngridients and giveFood.
Template method pattern is useful when you want to use some parent class's fields and when your implementation is not really a whole algorithm but only some 'logic' very specific to your hierarchy of classes.
On the other hand, when you find out that your template methods implementations are redundant or leads to duplication code across several subclasses of the same tree, prefer Strategy pattern so that your code will be factorized.
Also, template method working by the way of subclassing, you can't change your behaviour at runtime whereas with Strategy pattern, all you have to do is to use setter to change your behaviour whenever you wish.
In all other cases, those two patterns are very similar and you can often choose for the one you like.
Similarities:
Both Template method & Strategy are behavioural patterns.
Both patterns are used to change an algorithm by sub classes but with a difference - Partial or full
For better understanding of these two features, we have to understand core differences in implementation of these two patterns.
Core Differences:
Template method uses Inheritance and Strategy uses composition
The Template method implemented by the base class should not be overridden. In this way, the structure of the algorithm is controlled by the super class, and the details are implemented in the sub classes
Strategy encapsulates the algorithm behind an interface, which provide us ability to change the algorithm at run time
Related posts:
Real World Example of the Strategy Pattern
Template design pattern in JDK, could not find a method defining set of methods to be executed in order
Have a look at Template method and Strategy articles for better understanding.
Related
I do have a service which needs to handle two types of meal.
#Service
class MealService {
private final List<MealStrategy> strategies;
MealService(…) {
this.strategies = strategies;
}
void handle() {
var foo = …;
var bar = …;
strategies.forEach(s -> s.remove(foo, bar));
}
}
There are two strategies, ‘BurgerStrategy’ and ‘PastaStrategy’. Both implements Strategy interface with one method called remove which takes two parameters.
BurgerStrategy class retrieves meals of enum type burger from the database and iterate over them and perform some operations. Similar stuff does the PastaStrategy.
The question is, does it make sense to call it Strategy and implement it this way or not?
Also, how to handle duplications of the code in those two services, let’s say both share the same private methods. Does it make sense to create a Helper class or something?
does it make sense to call it Strategy and implement it this way or not
I think these classes ‘BurgerStrategy’ and ‘PastaStrategy’ have common behaviour. Strategy pattern is used when you want to inject one strategy and use it. However, you are iterating through all behaviors. You did not set behaviour by getting one strategy and stick with it. So, in my honour opinion, I think it is better to avoid Strategy word here.
So strategy pattern would look like this. I am sorry, I am not Java guy. Let me show via C#. But I've provided comments of how code could look in Java.
This is our abstraction of strategy:
public interface ISoundBehaviour
{
void Make();
}
and its concrete implementation:
public class DogSound : ISoundBehaviour // implements in Java
{
public void Make()
{
Console.WriteLine("Woof");
}
}
public class CatSound : ISoundBehaviour
{
public void Make()
{
Console.WriteLine("Meow");
}
}
And then we stick with one behaviour that can also be replaced:
public class Dog
{
ISoundBehaviour _soundBehaviour;
public Dog(ISoundBehaviour soundBehaviour)
{
_soundBehaviour = soundBehaviour;
}
public void Bark()
{
_soundBehaviour.Make();
}
public void SetAnotherSound(ISoundBehaviour anotherSoundBehaviour)
{
_soundBehaviour = anotherSoundBehaviour;
}
}
how to handle duplications of the code in those two services, let’s say both share the same private methods.
You can create one base, abstract class. So basic idea is to put common logic into some base common class. Then we should create abstract method in abstract class. Why? By doing this, subclasses will have particular logic for concrete case. Let me show an example.
An abstract class which has common behaviour:
public abstract class BaseMeal
{
// I am not Java guy, but if I am not mistaken, in Java,
// if you do not want method to be overriden, you shoud use `final` keyword
public void CommonBehaviourHere()
{
// put here code that can be shared among subclasses to avoid code duplication
}
public abstract void UnCommonBehaviourShouldBeImplementedBySubclass();
}
And its concrete implementations:
public class BurgerSubclass : BaseMeal // extends in Java
{
public override void UnCommonBehaviourShouldBeImplementedBySubclass()
{
throw new NotImplementedException();
}
}
public class PastaSubclass : BaseMeal // extends in Java
{
public override void UnCommonBehaviourShouldBeImplementedBySubclass()
{
throw new NotImplementedException();
}
}
The abstract factory pattern is useful when we have families of related classes, and we want to instantiate them without relying on the implementation. However, what's wrong with using the factory method pattern in such a situation?
Let's say that we want to construct cross-platform UI elements, e.g. TextBox and Button for Windows and macOS and treat them abstractly. This is the typical situation in which we use the abstract factory pattern, and we can do so by defining the following:
AbstractUIElementsFactory interface
WindowsUIElementsFactory implements AbstractUIElementsFactory
MacUIElementsFactory implements AbstractUIElementsFactory
TextBox abstract class
MacTextBox extends TextBox
WindowsTextBox extends TextBox
Button abstract class
MacButton extends Button
WindowsButton extends Button
and the application would decide which concrete factory to create (based on some OS discovery mechanism) and pass it to a UIApplication class, which instantiates a TextBox and a Button, and calls display on them (which are abstract methods that simply return a String).
The code for this situation:
package abstractFactory;
abstract class Button {
public abstract void display();
}
class MacButton extends Button {
public void display() {
System.out.println("macButton");
}
}
class WindowsButton extends Button {
#Override
public void display() {
System.out.println("winButton");
}
}
abstract class TextBox {
public abstract void display();
}
class MacTextBox extends TextBox {
#Override
public void display() {
System.out.println("macTextBox");
}
}
class WinTextBox extends TextBox {
#Override
public void display() {
System.out.println("winTextBox");
}
}
interface UICreatorAbstractFactory {
Button getButton();
TextBox getTextBox();
}
class MacFactory implements UICreatorAbstractFactory {
#Override
public Button getButton() {
return new MacButton();
}
#Override
public TextBox getTextBox() {
return new MacTextBox();
}
}
class WindowsFactory implements UICreatorAbstractFactory {
#Override
public Button getButton() {
return new WindowsButton();
}
#Override
public TextBox getTextBox() {
return new WinTextBox();
}
}
class UIApplication {
private UICreatorAbstractFactory factory;
UIApplication(UICreatorAbstractFactory _factory) {
factory = _factory;
}
public void displayUI() {
factory.getButton().display();
factory.getTextBox().display();
}
}
public class Main {
public static void main(String[] args) {
new UIApplication(new MacFactory()).displayUI();
}
}
This implementation allows us to get UI elements transparently from factory implementations and also UI elements implementations, which is largely why we would use the pattern.
Using the same TextBox, Button, and their derivatives, we can have a factory method implementation with two factory methods in the creator, UICreator, each of which returns an abstract UI element. And we derive the creator and make two specializations WindowsUICreator, and MacUICreator, and each of which returns the appropriate concrete UI element, as follows:
abstract class UICreator {
public void displayUI() {
getButton().display();
getTextBox().display();
}
protected abstract Button getButton();
protected abstract TextBox getTextBox();
}
class WindowsUICreator extends UICreator {
#Override
protected Button getButton() {
return new WindowsButton();
}
#Override
protected TextBox getTextBox() {
return new WinTextBox();
}
}
class MacUICreator extends UICreator {
#Override
protected Button getButton() {
return new MacButton();
}
#Override
protected TextBox getTextBox() {
return new MacTextBox();
}
}
public class Main {
public static void main(String[] args) {
new MacUICreator().displayUI();
}
}
What are the downsides of this design? I believe it provides the needed decoupling by not having to deal with any concrete classes, and also provides the proper extensibility in the sense that we can introduce new UI elements and give them new factory methods, or newly supported OSs and implement concrete creators for them. And if we can use the factory method pattern in the exact situation the abstract factory pattern was designed for, I don't understand why do we have it at all?
They are both about creating new objects but the factory method is used to create one product only while the Abstract Factory is about creating families of related or dependent products.
In the Abstract Factory pattern, a class delegates the responsibility of object instantiation to another object via composition, whereas the Factory Method pattern uses inheritance and relies on a subclass to handle the desired object instantiation.
I would like to show you an image from Saurav Satpathy's blog here which quickly can explain why you want abstract factory over factory method at times.
The argument for dependency injection and collection of related objects makes a lot of sense and here is a coded example by a great creator The Refactoring Guru on Abstract Factory and here is his example on factory method. The main difference between the examples in my opinion is the abstract factory better depicts the complexity of factories that create multiple types of objects. Additionally, it effectively divides the code in more classes, making each class simpler to understand (but creating more classes in total, of course).
Keep in mind this is not a very in depth analysis as of now, I want to see other people's opinions on the matter and give it some time to think for myself. I may come back in a couple of days with an edit (currently a bit busy, but I sneaked a quick opinion for you)
Edit #1 Inheritance
"Favor object composition over class inheritance. Inheritance breaks encapsulation, implement abstract classes, do not inherit concrete classes! - The Gang of Four on Design Patterns"
So object inheritance if you read the GoF's book: "Design Patterns Elements of Reusable Object-Oriented Software" is discouraged, especially when systems become more and more complex or higher in scope. Edit influenced by #FelipeLlinares great point indeed.
source: https://en.wikipedia.org/wiki/Factory_method_pattern
This diagram really alludes to Factory Method Pattern?
Why do we need Creator? Look at code example:
interface Product{
public String getName();
}
class ConcreteProduct1 implements Product {
#Override
public String getName() {
return "I'm product 1";
}
}
class ConcreteProduct2 implements Product {
#Override
public String getName() {
return "Im product 2!";
}
}
// CREATOR HERE
interface Creator{
public Product createProuct(String productClass);
}
class ConcreteCreator implements Creator{
#Override
public Product createProuct(String productClass) {
if(productClass.equals("1"))
return new ConcreteProduct1();
else if(productClass.equals("2"))
return new ConcreteProduct2();
else
return null; //
}
}
public class Test {
public static void main(String[] args) {
Creator c = new ConcreteCreator();
Product product = c.createProuct("1");
System.out.print(product.getName());
}
}
Code without Creator interface:
class ConcreteCreator{
public Product createProuct(String productClass) {
if(productClass.equals("1"))
return new ConcreteProduct1();
else if(productClass.equals("2"))
return new ConcreteProduct2();
else
return null; //
}
}
public class Test{
public static void main(String[] args) {
ConcreteCreator c = new ConcreteCreator();
Product product = c.createProuct("1");
System.out.print(product.getName());
}
}
So why do we need Creator interface? Is it in case i would add another factory method in future? If yes, is it still Factory Method Pattern or Abstract Factory Pattern? Could you give me some code examples with extensions to my Creator interface and implementation of ConcreteCreator which uses two methods?
Also how about generic Creator? It looks much simpler than many type specified Creators...:
interface Product{
public String getName();
}
class ConcreteProduct implements Product{
#Override
public String getName() {
return "I'm product 1";
}
}
interface Moveable{
public String move();
}
class Car implements Moveable{
#Override
public String move() {
return "moving...";
}
}
interface Creator<T>{
public T create();
}
class ConcreteCreatorProducts implements Creator<Product>{
#Override
public Product create() {
return new ConcreteProduct();
}
}
class ConcreteCreatorCar implements Creator<Car>{
#Override
public Car create() {
return new Car();
}
}
public class Test{
public static void main(String[] args) {
Creator<Product> productCreator = new ConcreteCreatorProducts();
Product product = productCreator.create();
Creator<Car> carCreator = new ConcreteCreatorCar();
Car car = carCreator.create();
}
}
In your example, you don't need a Creator interface, unless you want to have multiple implementations and swap between them. But the diagram is actually describing a slightly different pattern than you've implemented.
The way the factory method pattern is described there is based on the original design patterns book. It's a bit odd today, as it uses subclassing to configure a class, when we would encourage the use of composition instead. So, the diagram does show the factory method pattern, but different from the way it's described in many other places.
The factory method pattern is:
Define an interface for creating an object, but let subclasses decide
which class to instantiate. The Factory method lets a class defer
instantiation it uses to subclasses.
In the original pattern, Creator isn't an interface. By 'interface', they mean the factory method that Creator defines, not interfaces like Java has.
The factory method doesn't need a parameter. Instead of different types being returned based on the parameter, there are different types returned based on the subclass created.
Also, you wouldn't call createProduct from main, but from methods within Creator. Creator is the user of the factory method, so it defines a factory method, that may be abstract, and some other methods that use that method.
See the Java examples on the wikipedia page. The MazeGame class is the Creator. The constructor is used as the anOperation method, and there are multiple subclasses for creating different kinds of rooms.
Code is written so that human readers understand it.
This means that you as a programmer sometimes use the means of the language not because it is absolutely mandatory, but because it is the best way to communicate your intention.
As soon as you declare that something is an interface you make it clear that there is no "base class" - only an interface, and that any specific implementation is subtle detail not really important to people dealing with the corresponding objects.
In other words: yes, it is perfectly possible to implement a factory pattern where the part responsible for creating the actual objects is not an interface, but a fixed class. Especially when thinking about "internal" factories (that are not exposed to a public API and wide range of "different" end users) that case is probably even the more common approach. ( the code I write contains many factories, few of them would follow the above approach of "interfacing" almost everything )
Beyond that - keep in mind that programming is also often about balancing between different requirements. Example: you might (again for communicating intent) decide to declare a class that provides a certain functionality as final. So that nobody gets idea of extending that specific class. But doing so means that users of that API are all of a sudden affected in their choice of mocking frameworks. As mocking final classes is not something that you can do easily. When you are then consuming this API, and you want to write unit tests - then you are very happy about the fact that the public API is relying on interfaces, not classes. Because you can always mock interfaces - but as said, final classes can cause headache.
I should use and name a design pattern for following problem:
I have separate interfaces: Basic, Complex. All classes implement Basic. Some of the classes implement Complex but they have to inherit from Abstract class.
I was thinking about decorator but I don't know if I'm right.
Code is in Java.
I think something like Builder design pattern can be good for this case:
first Create an interface for the Basic
public interface Basic{
public void basicOp();
}
second: create an interface for the Complex one:
public interface Complex{
public void complexOp();
public Basic basicOp();
}
Third: create required classes which implements basic interface:(Class2)
public class abstractBasicA implements Basic {
#Override
public void basicOp() { ... }
}
fourth: create abstract required classes for complex interface
public abstract class AbstractClassComplexA implements Complex{
#Override
public complexOp() { ... }
#Override
public abstract Basic basicOp(){...}
}
fifth: create all other classes which extends above abstract class(Class3, Class4, Class5).
I think you should go with decorator pattern and use composition. A Complex should have a Basic member, which could manage the Basic part of the Complex type.
Below a short example.
package main;
public class Main {
public static void main(String[] args) {
Basic basic = new BasicImpl();
basic.basicOp();
// main.BasicImpl.op()
Complex ca = new ConcreteComplexA(basic);
ca.basicOp();
ca.complexOp();
// main.BasicImpl.op()
// main.ConcreteComplexA.complex()
Complex cb = new ConcreteComplexB(basic);
cb.basicOp();
cb.complexOp();
// main.BasicImpl.op()
// main.ConcreteComplexB.complex()
}
}
interface Basic {
void basicOp();
}
interface Complex extends Basic {
void complexOp();
}
class BasicImpl implements Basic {
#Override
public void basicOp() {
System.out.println("main.BasicImpl.basicOp()");
}
}
abstract class AbstractComplex implements Complex {
private final Basic basic;
public AbstractComplex(Basic basic) {
this.basic = basic;
}
#Override
public void basicOp() {
basic.basicOp();
}
}
class ConcreteComplexA extends AbstractComplex {
public ConcreteComplexA(Basic basic) {
super(basic);
}
#Override
public void complexOp() {
System.out.println("main.ConcreteComplexA.complex()");
}
}
class ConcreteComplexB extends AbstractComplex {
public ConcreteComplexB(Basic basic) {
super(basic);
}
#Override
public void complexOp() {
System.out.println("main.ConcreteComplexB.complex()");
}
}
If you want clean subtypting, you have to enforce behavioral conformance, i.e. adhere to all the invariants of the type (and of its methods) your inheriting from, you need Basic to extend Complex, but that feels counter-intuitive very often. But only if Complex redefines/specializes the inherited methods.
Sometimes it is best to make use of composition instead of inheritance. So instead of relying on a lot of subclasses, pull out the behaviour in an independent structure and inject it. Design patterns that could be playing here would be strategy and dependency injection (inversion of control).
Deep class hierarchies are often a smell indicator and often you run into problems since Java doesn't support trades and you get code duplication if you need the same behavior in different classes that don't share the same ancestor.
in the reference book "Design Patterns Elements of Reusable Object-Oriented Software" by the gang of four, the intent of the visitor pattern is explained as follow :
Represent an operation to be performed on the elements of an object structure. Visitor lets you define a new operation without changing the classes of the elements on which it operates.
Another advantage I read about the visitor pattern is that:
ADD A NEW OPERATION WITHOUT HAVING THE SOURCE CODE OF THE CLASSES..
I made a deep search in Google, but I did not find any example showing how to do that.
So let's take a simple example :
public interface MyInterface {
public void myMethod();
}
public class MyClassA implements MyInterface {
/* (non-Javadoc)
* #see com.mycomp.tutorials.designpattern.behavorials.MyInterface#myMethodA()
*/
public void myMethod() {
System.out.println("myMethodA implemented in MyClassA");
}
}
public class MyClassB implements MyInterface {
/* (non-Javadoc)
* #see com.mycomp.tutorials.designpattern.behavorials.MyInterface#myMethodA()
*/
public void myMethod() {
System.out.println("myMethod implemented in MyClassB");
}
}
So how would I add a new method myNewMethod() to this hierarchy of classes without changing them, using the visitor pattern?
You example is not a visitor pattern. It is just inheritance.
A visitor pattern first requires an visitor interface
interface ThingVisitor {
void visit(ThingA a);
void visit(ThingB b);
}
Now you need an interface Thing:
interface Thing {
void accept(ThingVisitor visitor);
}
And your implementation of, for example, ThingA would be
class ThingA implements Thing {
public void accept(final ThingVisitor visitor) {
visitor.visit(this);
}
}
Now you see the logic to handle the Thing types is contained in the implementations of ThingVisitor.
Let's say you have a Message class, and 2 subclasses Email and Sms.
You could have many operations on these two classes, like sendToOnePerson(), sendToSeveralPeople(). But you probably don't want to have these methods in the Email and Sms class directly, because it tightly couples them to the SMTP/phone system. And you would also like to be able to add other operations in the futre, like forward() or delete(), or whatever. So the first implementation you could use is
public void delete(Message message) {
if (message instanceof Email) {
deleteEmail(Email) message);
}
else if (message instanceof Sms) {
deleteSms((Sms) message);
}
}
But this is ugly: it's not object-oriented, and it will fail if there is a new VoiceMessage subclass appearing.
An alternative is to use the visitor pattern.
public interface MessageVisitor {
void visitEmail(Email email);
void visitSms(Sms sms);
}
public abstract class Message {
public void accept(MessageVisitor visitor);
}
public class Email extends Message {
#Override
public void accept(MessageVisitor visitor) {
visitor.visitEmail(this);
}
}
public class Sms extends Message {
#Override
public void accept(MessageVisitor visitor) {
visitor.visitSms(this);
}
}
This way, to implement send(), all you need is a MessageVisitor implementation that can send an email and send an Sms:
SendMessageVisitor visitor = new SendMessageVisitor();
message.accept(visitor);
And if you introduce a new delete() operation, you don't have to touch to Message classes at all. All you need is a DeleteMessageVisitor:
DeleteMessageVisitor visitor = new DeleteMessageVisitor();
message.accept(visitor);
So, basically, it's a bit like if you added polymorphic methods to the Message classes by not actually modifying the Message classes.
The visitor pattern assumes that you have a method in the classes you want to "visit" which accepts and executes the visitor, here is an example. The pattern is not motivated by adding functionality to foreign classes but to localize functionality in the visitors which would otherwise be spread over several classes, e.g. for saving elements (see the example).
Quick description of the visitor pattern.
The classes that require modification must all implement the 'accept' method. Clients call this accept method to perform some new action on that family of classes thereby extending their functionality. Clients are able to use this one accept method to perform a wide range of new actions by passing in a different visitor class for each specific action. A visitor class contains multiple overridden visit methods defining how to achieve that same specific action for every class within the family. These visit methods get passed an instance on which to work