0

I have the following classes in my system (python):

class Metric(ABC): def compute(self): -> float class Visualization(ABC) def visualize(self) class FirstMetric(Metric) def __init__(self, data1): def compute(self): -> float class FirstVisualization(Visualization) def __init__(self, plot_param1, data1) def visualize(self) class SecondMetric(Metric) def __init__(self, data1, data2): def compute(self): -> float class SecondVisualization(Visualization) def __init__(self, plot_param1, plot_param2, data1, data2) def visualize(self)

I have one Metric and one Visualization subclass for each different implementation. As you can see in the code, each of those two classes require the same data, only visualization requires extra plotting parameters. When I instantiate them, I never instantiate objects from different catalogs, i.e, I would never create a FirstMetric and a SecondVisualization together.

Since I always generate pairs Metric-Visualization, and they have similar inputs, I was wondering if it would make sense to use the Abstract Factory design pattern. It would look like this:

class AbstractFactory(ABC): def create_metric(self) -> Metric def create_visualization(self) -> Visualization class FirstFactory(AbstractFactory): def __init__(self, data1, plot_param1): self.data1 = data1 self.plot_param1 = plot_param1 def create_metric(self): return FirstMetric(self.data1) def create_visualization(self): return FirstVisualization(self.data1, self.plot_param1) class SecondFactory(AbstractFactory): def __init__(self, data1, data2, plot_param1, plot_param2): self.data1 = data1 self.data2 = data2 self.plot_param1 = plot_param1 self.plot_param2 = plot_param2 def create_metric(self): return SecondMetric(self.data1, self.data2) def create_visualization(self): return SecondVisualization(self.data1, self, data2, self.plot_param1, self.plot_param2)

I also wonder if this is "correct", since each Metric and Visualization subclass have different parameters in the constructor. Here, I am using the constructor of the Factory to solve this problem. All examples I have seen of AbstractFactory receive the parameters as arguments on the create_... methods, so maybe I am doing it wrong. Would you use this pattern here? If so, what would be the best implementation? If not, what would be a better solution?

Improve this question
3
  • "I also wonder if this is "correct", since each Metric and Visualization subclass have different parameters in the constructor" - that is perfectly fine/normal. You can also have your factory methods take in parameters if you want to (and are able to) supply some of them at product creation time (rather than at factory creation time). The abstract factory defines an interface for creating these objects - what that interface looks like is up to you; some of your parameters can be general, others factory-specific. Commented Oct 18, 2022 at 11:17
  • So in my case all factory methods would have no parameters (since they are defined at the subclass level), and I would supply all of them to the factory at factory creation time. I cannot supply them to the factory methods, because I would have to define them at the AbstractFactory. I understand that this is normal Commented Oct 18, 2022 at 11:30
  • I'm saying that's OK. You can design your factories in whatever way best suits your problem. There's no abstract factory police out there. In the original Design Patterns book, they show an example where they pass one parameter that came from the factory method, and an extra parameter that came from a private field of the factory itself. You can mix and match - based on how you intend to call the methods on the abstract factory instance, decide what to define on the AbstractFactory public interface, vs what to pass through concrete factory constructors or obtain in some other way. Commented Oct 22, 2022 at 1:42

0

Reset to default

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.