zoukankan      html  css  js  c++  java
  • python设计模式之简单工厂

      说到简单工厂立马在脑海中闪现的是八九十年代沿海地区的一座座小作坊,在当年基本可以说是万能造。 拿鞋子为例,顾客说要老北京布鞋,一批工人就哗啦啦赶老北京布鞋,当顾客说要板鞋, 球鞋, 还是山地鞋,只要你有需求他就能造, 唯一让人不满意的可能就是质量不太好吧。 哈哈回归正题讲我们的设计模式之简单工厂,简单工厂设计模式可以说是我们软件工厂的万能造,只要开发者想添加一个if else就能造一个你想要的对象,我们来看一看吧!

      简单工厂设计模式定义是:  创建一个简单工厂类,给定一个参数,根据这个参数工厂类给你实例化对应的实例。

     

      简单工厂设计模式的结构如下

    01、 创建产品基类

    class Shoes:
        def put(self):
            print("终于穿上新鞋了")

    02、创建产品子类

    class BeiJingShoes(Shoes):
        
        def put(self):
            print("终于穿上老北京鞋了")
    
    
    class BanShoes(Shoes):
    
        def put(self):
            print("终于穿上板鞋了")
            
            
    class MountShoes(Shoes):
    
        def put(self):
            print("终于穿上山地鞋了")

    03、 创建简单工厂

    class SimpleFactory:
    
        def produce_shoes(self, type):
            if type == "beijing":
                return BeiJingShoes()
            elif type == "ban":
                return BanShoes()
            elif type == "mount":
                return MountShoes()
            else:
                print("我们还不能生产这种鞋子")
    
    if __name__ == "__main__":
        factory = SimpleFactory()
        beijing_shoes = factory.produce_shoes("beijing")
        ban_shoes = factory.produce_shoes("ban")
        mount_shoes = factory.produce_shoes("mount")
        beijing_shoes.put()
        ban_shoes.put()
        mount_shoes.put()
        factory.produce_shoes("basketball")

    运行结果如下:

    /usr/local/bin/python3.7 /Users/bytedance/PycharmProjects/untitled1/简单工厂设计模式/simple.py
    终于穿上老北京鞋了
    终于穿上板鞋了
    终于穿上山地鞋了
    我们还不能生产这种鞋子
    
    Process finished with exit code 0

    04、总结

    1. 简单工厂设计模式不在23种设计模式之中
    2. 简单工厂设计模式生产的product最好继承同一基类
    3. 只要稍微修改简单工厂就可以添加新的生产产品的方式
    4. 如果简单工厂可生产产品过多极易使代码非常臃肿
    5. 最重要一点它的修改违背了设计模式的开闭原则

    最后还是奉上我们设计模式的八大原则:

    1. 依赖倒置原则(DIP)
    * 高层模块(稳定)不应该依赖于低层模块(变化),二者都应该依赖于抽象(稳定) 。
    * 抽象(稳定)不应该依赖于实现细节(变化) ,实现细节应该依赖于抽象(稳定)。
    2. 开放封闭原则(OCP)
    * 对扩展开放,对更改封闭。
    * 类模块应该是可扩展的,但是不可修改。
    3. 单一职责原则(SRP)
    * 一个类应该仅有一个引起它变化的原因。
    * 变化的方向隐含着类的责任。
    4. Liskov 替换原则(LSP)
    * 子类必须能够替换它们的基类(IS-A)。
    * 继承表达类型抽象。
    5. 接口隔离原则(ISP)
    * 不应该强迫客户程序依赖它们不用的方法。
    * 接口应该小而完备。
    6. 优先使用对象组合,而不是类继承
    * 类继承通常为“白箱复用”,对象组合通常为“黑箱复用” 。
    * 继承在某种程度上破坏了封装性,子类父类耦合度高。
    * 而对象组合则只要求被组合的对象具有良好定义的接口,耦合度低。
    7. 封装变化点
    * 使用封装来创建对象之间的分界层,让设计者可以在分界层的一侧进行修改,而不会对另一侧产生不良的影响,从而实现层次间的松耦合。
    8. 针对接口编程,而不是针对实现编程
    * 不将变量类型声明为某个特定的具体类,而是声明为某个接口。
    * 客户程序无需获知对象的具体类型,只需要知道对象所具有的接口。
    * 减少系统中各部分的依赖关系,从而实现“高内聚、松耦合”的类型设计方案
  • 相关阅读:
    golang之panic,recover,defer
    Golang之函数练习
    Golang之strings包
    Golang之字符串操作(反转中英文字符串)
    keil中使用——变参数宏__VA_ARGS__
    到底该不该用RTOS——rtos的优点
    c语言联合union的使用用途
    c语言的#和##的用法
    c语言位域的使用注意事项——数据溢出
    基于 Keil MDK 移植 RT-Thread Nano
  • 原文地址:https://www.cnblogs.com/lifei01/p/13219435.html
Copyright © 2011-2022 走看看