请各位指点下疑惑,工厂方法到底解决了什么问题,为什么比简单工厂好

一直以来都有一个困惑,简单工厂模式升级到工厂方法模式之后,核心问题解决了吗
class TransportFctory {
    public function makeTransport($type) {
        switch ($type){
        case "ship":
            $transport = new ShipTransport();
            break;
        case "car":
            $transport = new CarTransport();
            break;
        default:
            throw NotSupprotedTransportException();
        }
    }
}

class ShipTransport extend  Transport{
        public function transport(){
            //
        }
}

class CarTransport extend  Transport{
        public function transport(){
            //
        }
}
这种在调用的时候每新增一种运输方式的确会改动factory里的代码,但是如果换乘工厂方法模式
class Factory {
    public funtion makeTransport(){
    //
    }
}
calss ShipFactory extends Factory {
    public funtion makeTransport(){
        return new ShipTransport();
    }
}

calss CarFactory extends Factory {
    public funtion makeTransport(){
        return new CarTransport();
    }
}
使用了工厂方法模式之后,如果还是想客户端控制不同的type,那么是不是还是需要有一个地方进行type值的判断,然后返回不同的factory, 如果是的话,我感觉并没有比简单工厂更好吧。

一点疑惑,请各位指教。

《L01 基础入门》
我们将带你从零开发一个项目并部署到线上,本课程教授 Web 开发中专业、实用的技能,如 Git 工作流、Laravel Mix 前端工作流等。
《L02 从零构建论坛系统》
以构建论坛项目 LaraBBS 为线索,展开对 Laravel 框架的全面学习。应用程序架构思路贴近 Laravel 框架的设计哲学。
讨论数量: 2
使用了工厂方法模式之后,如果还是想客户端控制不同的type,那么是不是还是需要有一个地方进行type值的判断,然后返回不同的factory, 如果是的话,我感觉并没有比简单工厂更好吧。

你这句话的理解不正确,工厂方法并不是想解决客户端判断 type 的问题,换句话说即使使用了工厂方法,客户端该判断 type 还得判断,和用不用工厂方法无关。

工厂方法的好处在于每一个子工厂都实现了母工厂接口,以至于在客户端调用的时候,我们尽管调用方法即可,因为有接口做保障,调方法得到的一定就是我们想要的结果。

这个文章可参考 refactoringguru.cn/design-patterns...
file

2年前 评论

file
简单工厂改为工厂方法模式其实就是符合这个开闭原则,当你面对复杂的业务的时候,你会发现使用接口可扩展的方式,代码会更具可读性和可扩展性。

你的问题的核心,就像为 php 程序员要遵循 psr 规范一样:stuck_out_tongue:

2年前 评论
早起的虫子 (楼主) 2年前
梧桐树下 (作者) 2年前

讨论应以学习和精进为目的。请勿发布不友善或者负能量的内容,与人为善,比聪明更重要!