设计模式篇(三)——工厂模式

一、简介

工厂模式(Factory Pattern) 同属于创建型模式,该模式顾名思义,就是像工厂一样生产一个或多个对象。

定义:在 工厂模式 中,我们创建对象时不对外公开创建逻辑,而是通过 工厂类 来创建的对象。这样就达到了创建对象和使用对象的分离。

实现要素:通过 工厂类 生成对象。

工厂模式建造者模式 比较类似,同样都是将对象的构造和表示分离,不同的是,前者注重于生成对象的结果,后者则是注重于生成对象的过程。

二、实现

工厂模式 的实现非常简单。说到工厂我们通常会想到手机厂、汽车厂,那么本篇文章就以汽车工厂为例,来对 工厂模式 进行剖析。

1、最简单的实现
class Car(val brand:String,val modelNum:String)

class CarFactory{

    fun produceCar(name:String,modelNum: String): Car {
        return Car(name,modelNum)
    }
}

fun main() {
    val car = CarFactory().produceCar("领克","05")
}
2、稍微改进
  1. 经过上面的例子,我们可以通过 CarFactory 对象来创建一个 Car 对象,但是我们发现,这个produceCar() 方法完全可以变成一个静态方法,这样就可以不用创建 CarFactory 对象,而是直接调用该方法。
  2. 我们仍然可以单独访问 Car 这个对象,可以跨过 CarFactory 直接new 一个 Car ,所以我们必须采取一些操作。

第一个改进点加个关键词就完事了,第二个改进点也很简单,只需要限制 Car 的构造函数即可,一般我们会使用内部类这种方式,来加强 CarCarFactory 之间的联系,:

//注 意 私 有 化 构 造 方 法!!!
class Car private constructor(val brand:String,val modelNum:String){

    class CarFactory{

        companion object{
            
            @JvmStatic
            fun produceCar(name:String,modelNum: String): Car {
                return Car(name,modelNum)
            }
        }
    }
}

fun main() {
    val car = Car.CarFactory.produceCar("领克","05")
}
3、返回不同对象

对于 Car 这个类来说实在是太抽象了,我们可以将它作为抽象类,然后创建多个实现类:

abstract class Car(val name:String,val modelNum:String){

    abstract fun getProductPlace():String

    class CarFactory{

        companion object{

            @JvmStatic
            fun<C:Car> produceCar(clazz: Class<C>): Car? {
                when(clazz){
                    Lynk::class.java->{
                        return Lynk("05")
                    }
                    VW::class.java->{
                        return Lynk("迈腾")
                    }
                    BMW::class.java->{
                        return Lynk("750i")
                    }
                }
                return null
            }
        }
    }
}

class Lynk(modelNum: String) : Car("领克", modelNum){

    override fun getProductPlace(): String  = "中国"
}

class VW(modelNum: String) : Car("打死奥拓", modelNum){

    override fun getProductPlace(): String  = "德国"
}

class BMW(modelNum: String) : Car("宝骏", modelNum){

    override fun getProductPlace(): String  = "德国"
}


fun main() {
    val lynk = Car.CarFactory.produceCar(Lynk::class.java)
    val bmw= Car.CarFactory.produceCar(BMW::class.java)
    lynk?.getProductPlace()
}

三、相关源码

  1. MVVM 模式中需要创建一个 ViewModel 对象,我们通常会调用ViewModelProviders.of(this).get(MainViewModel::class.java) 来创建一个 ViewModel 对象,但是我要展示的例子不是这行代码……
    在这里插入图片描述
    而是这行代码:ViewModelProvider.NewInstanceFactory().create(XXXViewModel::class.java)
class ViewModelProvider{

	... ...
	
	public static class NewInstanceFactory implements Factory {

        public <T extends ViewModel> T create(@NonNull Class<T> modelClass) {
            try {
                return modelClass.newInstance();
            } catch (InstantiationException e) {
                ... ...
            }
        }
    }
}

代码太简单了,自己看吧。(因为 lifecycle 组件一直在更新,可能会导致源码不一,不用在意这些细节)

四、小结

工厂模式 实现简单,应用广泛,实乃居家必备之良药✌。

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 5
    评论
1、 IOS设计模式的六大设计原则之单一职责原则(SRP,Single Responsibility Principle) 定义   就一个类而言,应该仅有一个引起它变化的原因。 定义解读   这是六大原则中最简单的一种,通俗点说,就是不存在多个原因使得一个类发生变化,也就是一个类只负责一种职责的工作。 优点 类的复杂度降低,一个类只负责一个功能,其逻辑要比负责多项功能简单的多; 类的可读性增强,阅读起来轻松; 可维护性强,一个易读、简单的类自然也容易维护; 变更引起的风险降低,变更是必然的,如果单一职责原则遵守的好,当修改一个功能时,可以显著降低对其他功能的影响。 问题提出   假设有一个类C,它负责两个不同的职责:职责P1和P2。当职责P1需求发生改变而需要修改类C时,有可能会导致原本运行正常的职责P2功能发生故障。 解决方案   遵循单一职责原则。分别建立两个类C1、C2,使C1完成职责P1,C2完成职责P2。这样,当修改类C1时,不会使职责P2发生故障风险;同理,当修改C2时,也不会使职责P1发生故障风险。   说到这里,大家会觉得这个原则太简单了。稍有经验的程序员,即使没有听说过单一职责原则,在设计软件时也会自觉的遵守这一重要原则。在实际的项目开发中,谁也不希望因为修改了一个功能导致其他的功能发生故障。而避免出现这一问题的方法便是遵循单一职责原则。虽然单一职责原则如此简单,并且被认为是常识,即便是经验丰富的程序员写出的程序,也会有违背这一原则的代码存在。为什么会出现这种现象呢?因为有职责扩散。实际项目中,因为某种原因,职责P被分化为粒度更细的职责P1和P2。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 5
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值