如何优化此 UML 图 class 以生成文档

How to optimize this UML diagram class for document generation

根据这个class图,其目的是模拟生成几种类型的文档:

此处提供更大尺码:https://www.dropbox.com/s/heub3dmh7sznkih/document_generation.png?dl=0

客户端代码将使用 DocumentGenerator class,这是一个文档工厂,描述所需文档的类型和服务(检查是可选的,只有发送文档才需要)。

我正在为红色的 classes 苦苦挣扎。如果所有保险公司都对发票、估价等使用相同的文档模型,这就不是什么大问题。但是有一家公司需要打印不同的派遣文件模型,而且更多的公司很可能会发生这种情况,不仅是派遣文件,还有其他文件。

猜猜如果我为每个公司专门化每个文档子class会发生什么?这将是代码重复的噩梦。

两种设计模式(strategydecorator)可能会满足我的要求,以便支持组合而不是继承,但我不能弄清楚如何抓住这个想法。

欢迎提出任何建议。

这是此图表的 XMI 文件的 link,如果您想使用它: https://www.dropbox.com/s/n1l5ohdnojvvkze/documents_generation.xmi?dl=0

编辑:

我知道怎么做了。也许不需要新的 class。实施(PHP):

// DocumentGenerator Class
class DocumentGenerator {

    const INVOICE_TYPE  = 1;
    const ESTIMATE_TYPE = 2;
    const DISPATCH_TYPE = 3;

    private __construct() {}

    public function getInstance($type, Service $service)
    {
        switch($type) {
            case self::ESTIMATE_TYPE:
                $document = new Estimate($service);
                break;
            case self::DISPATCH_TYPE:
                $document = new Dispatch($service);
                break;
            default:
            case self::INVOICE_TYPE:
                $document = new Invoice($service);
        }
        return $document;
    }
}


// Document Class
abstract class Document {

    protected $service;

    public function __construct(Service $service) 
    {
        $this->service = $service;
    }

    abstract protected function show();
    // ....
}


// Invoice Class
class Invoice extends Document {

    const PATH_SEGMENT = 'invoice';

    public function show()
    {
        // the key point
        $this->view->setPath(self::PATH_SEGMENT . '/' . $service->getCompanyName());
        $this->view->create();   
    }

    // ...
}

// creating an invoice, no matter the company
$document = DocumentGenerator::getInstance(DocumentGenerator::INVOICE_TYPE, $service);
$document->show();

公司名称和文档类型将导致视图使用正确的模板。我仍然不确定这是否是一个好的解决方案,因为我有硬编码的命名约定来访问特定的模板文件。

还有其他建议吗??

如果您有不同的要求,您可能需要不同的实现。如果您有一些通用格式的文档,您可以创建一些覆盖该文档的超类。如果你对不同的公司有不同的实现,那么你需要实现完全不同的 Dispatch/Estimate/Invoice 类 我们你会发现一些概括(这将启用代码重用)。无论如何:不同的需求导致不同的代码。我不明白这会如何导致一场噩梦。一个替代方案总是(尽管在大多数情况下由于笨蛋而不可能)它说服或统治一些常见的文档格式。