简单工厂（UML）中的聚合或依赖 [英] Aggregation or Dependency in the Simple Factory (UML)

问题描述

在我学习的课程中， PizzaStore 使用 simplePizzaFactory 类处理具体的比萨饼实例，带有下图（课程材料中提供）：

我在python中重新编写的代码：

 ＃Pizza的超类及其子类在其他地方定义elswhere 
 
类SimplePizzaFactory：
 def create_pizza（self，type_of_pizza）：
如果type_of_pizza == cheese：
 pizza = CheesePizza（）
 elif type_of_pizza == pepperoni：
 pizza = PepperoniPizza（）
 
 elif type_of_pizza == clam：
 pizza = ClamPizza（）
 
 elif type_of_pizza == viggie：
比萨= ViggiePizza（）
其他：
引发异常（，您需要指定一种比萨饼。）
 
返回比萨饼
 
 
类PizzaStore：
 def __init __（self，pizza_factory_obj）：
 self.pizza_factory_obj = pizza_factory_obj 
 
 def order_pizza（self，type_of_pizza）：
 type_of_pizza = type_of_pizza .lower（）
 pizza = self.pizza_factory_obj.create_pizza（type_of_pizza）
 pizza.prepare（）
 pizza.bake（）
 pizza.box（）
返回比萨
 
打印（ ===================================== ===================）
 factory = SimplePizzaFactory（）
 store = PizzaStore（factory）
 store.order_pizza（ ;奶酪）
 store.order_pizza（ viggie）
 
  

问题：

（根据课程资料）进行概括：

<我会理解第一个箭头是聚合（因为创建了simplePizzaFactory的对象并将其作为参数发送给PizzaStore），但是第二个箭头又是如何聚合的呢？

如果我对第一个箭头的理解不正确，我希望在这一部分以及我的理解上有更多的说明，这应该不是更有意义吗？
对代码的任何注释也将受到赞赏

解决方案

我知道第一个箭头是聚合（因为创建了simplePizzaFactory的对象并将其作为参数发送给PizzaStore）

这不是因为构造函数（或 PizzaStore （ Client ）的任何其他方法）都会收到 SimplePizzaFactory 的实例，该实例存在首次聚合，甚至没有简单的关联。 / p>

对我来说，这两个汇总都是错误的。

• SimpleFactory 不知道客户端正在使用它，因此更重要的是没有聚集


• 产品不知道 SimpleFactory 正在创建它，所以没有任何聚集。

图可以是（ Pizza 是抽象但可能是 interface 吗？）：

请注意，在第一张图中， SimplePizzaFactory 和 Pizza 之间的关系也是错误的，因为在 SimplePizzaFactory 中没有属性>记住 Pizza 的实例，与 PizzaStore 具有属性以保存SimplePizzaFactory *的实例相反，很明显地使用构造型 create 。

In a course I'm taking, a PizzaStore uses a simplePizzaFactory class that handles concrete pizza instantiation, described with the following diagram (as provided in the course material):

Code that I re-wrote in python:

# Pizza's superclass and it's subclasses are defined elswhere

class SimplePizzaFactory:
    def create_pizza(self,type_of_pizza):
        if type_of_pizza == "cheese":
            pizza = CheesePizza()
        elif type_of_pizza == "pepperoni":
            pizza = PepperoniPizza()

        elif type_of_pizza == "clam":
            pizza = ClamPizza()

        elif type_of_pizza == "viggie":
            pizza = ViggiePizza()
        else:
            raise Exception("You need to specify a type of pizza.")
        
        return pizza


class PizzaStore:
    def __init__(self, pizza_factory_obj):
        self.pizza_factory_obj = pizza_factory_obj

    def order_pizza(self,type_of_pizza):
        type_of_pizza = type_of_pizza.lower() 
        pizza = self.pizza_factory_obj.create_pizza(type_of_pizza) 
        pizza.prepare()
        pizza.bake()
        pizza.box()
        return pizza

print("========================================================")
factory = SimplePizzaFactory()
store = PizzaStore(factory)
store.order_pizza("Cheese")
store.order_pizza("viggie")

Question:

Generalized by (from the course material):

I'd understand that the first arrow is aggregation (since an object of the simplePizzaFactory is created and sent to the PizzaStore as an argument) but how is the second arrow is also aggregation? shouldn't it make more sense to be a dotted dependency arrow?

I'd appreciate more clarification on this part and on my understanding as well if I was incorrect regarding the first arrow. Any comments on the code would be also appreciated

解决方案

I'd understand that the first arrow is aggregation (since an object of the simplePizzaFactory is created and sent to the PizzaStore as an argument)

This is not because the constructor (or any other method) of the PizzaStore (Client) receive an instance of the SimplePizzaFactory that there is the first aggregation nor even a simple association.

For me both aggregations are wrong.

• the SimpleFactory does not know the Client using it, so a fortiori there is no aggregation
• the Product does not know the SimpleFactory creating it, so a fortiori there is no aggregation.

The diagram can be (Pizza is abstract but may be it is an interface ?):

Note in your first diagram the relation between SimplePizzaFactory and Pizza is wrong too in the sense there is no attribute in SimplePizzaFactory to memorize instances of Pizza, contrarily to PizzaStore having an attribute to save an instance of SimplePizzaFactory*, it is much clear to use a dependency stereotyped create.

这篇关于简单工厂（UML）中的聚合或依赖的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！