79621
Question:
I'm learning Desgin patterns and come across very weird example in <a href="https://www.tutorialspoint.com/design_pattern/abstract_factory_pattern.htm" rel="nofollow">HERE</a>. If we got a class:
public abstract class AbstractFactory {
abstract Color getColor(String color);
abstract Shape getShape(String shape) ;
}
which as we can see, has 2 types of methods which creates Objects: colors and shapes. This class is abstract so we have to create concrete implementation of this, so lets assume that we have:
public class ShapeFactory extends AbstractFactory {
@Override
public Shape getShape(String shapeType){
// I skip implementation to keep post brief
}
@Override
Color getColor(String color) {
return null; // It's useless method in this class!
}
}
and second implementation:
public class ColorFactory extends AbstractFactory {
@Override
public Shape getShape(String shapeType){
return null; // It's useless method in this class!
}
@Override
Color getColor(String color) {
// I skip implementation to keep post brief
}
}
And here comes my question, in both cases (concrete factories) there is an method that is completly useless and shoudn't be there, but as we created AbstractFactory class we have to implement both methods. Isn't it bad practice in programming to create useless methods in classes that don't need it? Should it be done in other way not as website suggest?
Answer1:@Michael213 - Your concrete implementations are not correct. For sure they do not follow Abstract Factory pattern. Abstract factory talks about families of product. abstract factory sample (with my assumptions) will look like following code. your example using only one method will be misuse of pattern and will break soon.
I have already answer similar question please have a look to that also <a href="https://stackoverflow.com/questions/46384358/what-are-the-real-benefits-of-using-the-abstract-factory-in-the-following-exampl/46407888#46407888" rel="nofollow">What are the real benefits of using the Abstract Factory in the following example, instead of the factory method?</a>
public abstract class AbstractFactory {
abstract Color getColor(String color);
abstract Shape getShape(String shape) ;
}
/**
* CONCRETE FACTORY1
*/
class HighResolutionFactory extends AbstractFactory{
Color getColor(String color){
return new HighResolutionColor();
}
Shape getShape(String shape){
return new HighResolutionShape();
}
}
/**
* CONCRETE FACTORY2
*/
class LowResolutionFactory extends AbstractFactory{
Color getColor(String color){
return new LowResolutionColor();
}
Shape getShape(String shape){
return new LowResolutionShape();
}
}
class Color{} // ABSTRACT PRODUCT 1
class Shape{} // ABSTRACT PRODUCT 2
class HighResolutionColor extends Color{}// CONCRETE PRODUCT1 FACT 1
class HighResolutionShape extends Shape{}// CONCRETE PRODUCT2 FACT 1
class LowResolutionColor extends Color{}//...
class LowResolutionShape extends Shape{}
Answer2:Yes, that tutorial doesn't seem the best in that regards. It is not ideal although it still counts as a factory design pattern.
Answer3:AbstractFactory is wrong. You do not have to think of a factory that makes different objects. It is right to make separate factories for each different type.
public interface AbstractColorFactory {
public Color getColor(String color);
}
public interface AbstractShapeFactory {
public Shape getShape(String shape);
}
public class ColorFactory implements AbstractColorFactory {
public Color getColor(String color) {
return ....
}
}
public class ShapeFactory implements AbstractShapeFactory {
public Shape getShape(String shape) {
return ....
}
}
![Exception Using PayPal-PHP-SDK [Http response code 400]](/skin/wt/img/t.gif)