Résumé Usine modèle - code inutilisé

Question

J'apprends des modèles Desgin et rencontre un exemple très étrange dans HERE. Si nous avons une classe:

public abstract class AbstractFactory { 
abstract Color getColor(String color); 
abstract Shape getShape(String shape) ; 
} 

qui, comme on peut le voir, a 2 types de méthodes qui crée des objets: des couleurs et des formes. Cette classe est abstraite si nous devons créer la mise en œuvre concrète de cette, laisse supposer que nous avons:

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! 
} 
} 

et deuxième mise en œuvre:

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 

} 
} 

Et ici vient ma question, dans les deux cas (béton usines) il ya une méthode qui est complètement inutile et ne devrait pas être là, mais comme nous avons créé la classe AbstractFactory nous devons implémenter les deux méthodes. N'est-ce pas une mauvaise pratique en programmation de créer des méthodes inutiles dans les classes qui n'en ont pas besoin? Devrait-il être fait autrement, pas comme le suggère le site Web?

Answer 1

@ Michael213 - Vos implémentations concrètes ne sont pas correctes. Pour sûr, ils ne suivent pas le modèle Abstract Factory. Usine abstraite parle de familles de produits. échantillon d'usine abstrait (avec mes hypothèses) ressemblera à du code suivant. votre exemple utilisant une seule méthode sera une mauvaise utilisation du modèle et se brisera bientôt.

Je l'ai déjà répondre à la même question s'il vous plaît allez voir que aussi 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{} 

Answer 2

Oui, ce tutoriel ne semble pas le meilleur à cet égard. Ce n'est pas idéal bien qu'il compte toujours comme un motif de conception d'usine.

Answer 3

AbstractFactory est incorrect. Vous n'avez pas à penser à une usine qui fabrique des objets différents. Il est juste de faire des usines séparées pour chaque type différent.

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 .... 
    } 
}