当不同的库创建电子表格时使用哪种设计模式?

时间:2017-05-24 14:20:13

标签: php oop design-patterns refactoring

在我的控制器类中,我只想使用一个电子表格类来处理与电子表格创建,保存,加载,写入等相关的所有功能。

目前我正在使用一个开源库phpspreadsheet来创建电子表格,如果以后我想将其更改为另一个电子表格创建库,我不想在控制器类上做太多改动,而是,我可以为这个库创建另一个类,比如Spreadsheetlib2。那么哪种设计模式更适合在这里使用? “桥”或适配器?

// Bridge Pattern我现在正在尝试。

interface SpreadsheetInterface {

    public function create();

    public function write();

}


class Spreadsheet extends AbstractSpreadsheet {

    public function create() {

    }
}



class PhpSpreadsheet implements SpreadsheetInterface {

    public function create() {

    }
}


abstract class AbstractSpreadsheet {

    protected $spreadsheet;

    protected function __construct(SpreadsheetInterface $spreadsheet) {
        $this->spreadsheet = $spreadsheet;
    }
}

2 个答案:

答案 0 :(得分:1)

我真的非常关注“使用什么样的模式”。模式不是神奇的食谱,要编写代码。它们只是“简写描述”,用于描述您已编写的内容,以及其他开发人员。

我这样做的方法是创建一个包装器(我认为它算作“适配器”),它实现了一些控制器所依赖的特定接口。在这个包装器中,我将PhpSpreadsheet实例作为依赖项传递(或直接在该包装器中创建它的新实例)。

当你的控制器调用包装器上的方法时,它会将调用转发给底层的“电子表格类。

答案 1 :(得分:0)

这是Doctrine用来定义Connection接口的一个小技巧,同时扩展了PDO。

interface Connection
{
    public function prepare ($statement, array $driver_options = array());
}

class PdoConnection extends \PDO implements Connection
{

}

因此,他们希望根据所连接的数据库的要求定义一个可以实现的接口。但是他们希望保持API与PDO非常相似,但是PDO没有实现接口,所以他们不得不通过在实现PDO的同时扩展Connection来捎带它,因此{{1} }无意中实现了PDO

的方法

你可以做同样的事情。选择您最喜欢的电子表格库并从其方法创建一个接口,创建一个新类,扩展它然后实现您的界面。

现在,当您想要切换实现时,您最喜欢的库应该为您提供了大量的方法签名来实现另一个版本。