0

I'm learning Desgin patterns and come across very weird example in HERE. 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?

Michael213
  • 317
  • 3
  • 11
  • Are you asking, any way to skip overriding one of the method ? – Ravi Oct 08 '17 at 12:14
  • That tutorial makes no sense at all. You are right to be confused. – cpp beginner Oct 08 '17 at 12:17
  • In some point yes. I'm confused becouse patterns should make the code more relevant, but in these case it seem's to me far away from good practise. So what do you propose to change in this code? – Michael213 Oct 08 '17 at 12:18
  • 2
    That tutorial is nonsense. According to wikipedia (https://en.wikipedia.org/wiki/Abstract_factory_pattern): "The abstract factory pattern provides a way to encapsulate a group of individual factories that **have a common theme**" - in the tutorial this common theme does not exist. You can find a better example at http://java-design-patterns.com/patterns/abstract-factory/ – Thomas Kläger Oct 08 '17 at 13:09

3 Answers3

3

@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 What are the real benefits of using the Abstract Factory in the following example, instead of the factory method?

    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{}
Kedar Tokekar
  • 418
  • 3
  • 10
0

Yes, that tutorial doesn't seem the best in that regards. It is not ideal although it still counts as a factory design pattern.

Shai
  • 26
  • 1
0

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 ....
    }
}
mr mcwolf
  • 2,574
  • 2
  • 14
  • 27
  • Yes, but in these approach we do nothing more than normal Factory Pattern! We only add additional abstract class – Michael213 Oct 08 '17 at 12:19
  • An abstract class is used when you reuse logic. In this case there is no reuse of logic, so it is preferable to use interfaces instead of abstract classes. You should keep in mind that `Color` and `Shape` should also be interfaces (or abstract classes). If there are specific instances, it is better to use the static method `Color.newInstance(String)` and `Shape.newInstance(String)` factories. Still, you yourself notice that in your version you have to do the implementation of methods that you will never use. – mr mcwolf Oct 08 '17 at 12:30