混合装饰器模式和工厂模式

发布于 2024-10-18 22:03:28 字数 1454 浏览 1 评论 0原文

我们目前使用 Microsoft 的用户界面流程。 这基本上是一个 MVP“框架”。 控制器通过输入/输出参数相互通信。

控制器定义了这两个方法void OnEnterTask(object inputArguments)OutputArguments OnLeaveTask()。 基本上所有输入参数都包含 xml 数据。

输入参数只是 dto 的,因此由控制器决定如何解释 xml。

场景:

CalculateProductInputArgs -> 产品控制器 -> CalculateProductOutputArgs

如果产品控制器只需要处理运行良好的单个产品,则 。 但它需要能够与 CompositeProductController 进行通信。 它发送CalculateCompositeProductInput/OutputArgs,

创建的装饰器的组合

所以我的想法是由工厂代码(伪python)

class Processor:
    """abstract"""
    def ProcessInput(input):
        pass

    def ProcessOutput(output):
        pass

class ProductProcessor(Processor):
    """implements specific product behaviour"""
    pass

class CompositeProductProcessor(ProductProcessor):
    """implements specific product behaviour"""
    def __init__(productprocessor):
        self.processor = productprocessor

    def ProcessInput(input)
        productInput = input.Product
        compositeData = input.CompositeData
        self.processor(productInput)    

class Factory:
    def CreateProcessor(input):
        productprocessor = ProductProcessor() #maybe a specialized processor
        if input.IsComposite():
            composite = CompositeProductProcessor(productprocessor)
            return composite
        return productprocessor

:我的简单问题。 这是一个好的做法吗?或者你有更好的想法吗?

问候 :)

We currently use User Interface Process from Microsoft.
Which basically tends to be an MVP "Framework".
Controllers communicate with each other over Input/Output-Arguments.

A controller defines these two methods void OnEnterTask(object inputArguments), OutputArguments OnLeaveTask().
Basically all inputarguments contain xml-data.

the inputarguments are just dto's, so its up to the controller how to interpret the xml.

the scenario:

CalculateProductInputArgs -> ProductController -> CalculateProductOutputArgs

if the productcontroller just needs to handle single products that work very well.
but it needs to be able to communicate with a CompositeProductController.
Which sends CalculateCompositeProductInput/OutputArgs

so my thougts are a combination of decorators which is created by a factory

code (pseudo python):

class Processor:
    """abstract"""
    def ProcessInput(input):
        pass

    def ProcessOutput(output):
        pass

class ProductProcessor(Processor):
    """implements specific product behaviour"""
    pass

class CompositeProductProcessor(ProductProcessor):
    """implements specific product behaviour"""
    def __init__(productprocessor):
        self.processor = productprocessor

    def ProcessInput(input)
        productInput = input.Product
        compositeData = input.CompositeData
        self.processor(productInput)    

class Factory:
    def CreateProcessor(input):
        productprocessor = ProductProcessor() #maybe a specialized processor
        if input.IsComposite():
            composite = CompositeProductProcessor(productprocessor)
            return composite
        return productprocessor

my simple question.
is it a good practice? or do you have better ideas?

greetings :)

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

静水深流 2024-10-25 22:03:28

有一个工厂来决定您需要创建什么装饰器是非常合理的。

我可以建议的唯一更改是您为 CompositeProductProcessor 找到一个不同的名称,因为它不是复合模式的实现,并且命名可能会让读者感到困惑。

It's quite reasonable to have a factory that decides what decorator(s) you need to create.

The only change I can suggest is that you find a different name for CompositeProductProcessor as it's not an implementation of the Composite pattern, and the naming might be confusing to the reader.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文