Unity应用架构设计(7)——IoC工厂理念先行

简介:

一谈到 『IoC』,有经验的程序员马上会联想到控制反转,将创建对象的责任反转给工厂。IoC是依赖注入 『DI』 的核心,大名鼎鼎的Spring框架就是一个非常卓越的的控制反转、依赖注入框架。遗憾的是,我们显然不能在Unity 3D中去使用Spring框架,但思想是相通的——IoC也好,控制反转也罢,本质上是一个工厂,或者又被称为容器,我们可以自己维护一个工厂来实现对对象的管理,这也是本文的核心内容。

工厂模式初探

工厂,顾名思义,就是生产对象的地方。如果之前没有接触过设计模式,你可能会疑惑,我直接使用 『new』 关键字难道不能创建对象吗?为什么还要大费周章的让工厂来创建?当然这是没错的,直接使用 『new』 关键字很简洁,也很易懂,但你考虑过对象的释放吗?你可能会说不用考虑啊,GC会帮我们回收啊。

其实问题就出在这里,因为你没有考虑对象管理的动机,所以就不会有工厂这个概念。试想一下,使用ADO.NET或者JDBC去访问数据库,我们是不是要先建立一个Connection,当工作结束后,Close了这个连接。当再一次需要连接数据库时,再建立一次Connection,这背后其实有隐患。因为和数据库建立连接是非常耗时的,只是我们感受不到。我们能不能在关闭连接时,不销毁对象,而是将其放到一个对象池,当下一次请求来时,直接从对象池中获取。这就是工厂的动机,对对象的创建和释放进行管理,这样可以有效的提高效率。

o_objectpool.png

注:释放指的是对象实现了IDisposable接口的非托管资源,在uMVVM框架,工厂维护的都是托管资源,销毁由GC决定

工厂的分类

在uMVVM框架中,我将工厂分为三类:单例(Singleton),临时(Transient),池(Pool)。

  • Singleton :该工厂生产的对象是单例的,即一旦生产出来的对象将处理所有的请求,不会因为不同的请求而产生新的对象,通常需要考虑多线程并发问题
  • Transient :该工厂生产的对象是临时的,转瞬即逝的,即每一次请求产生一个新对象,处理请求完毕后就被销毁
  • Pool:该工厂并不会无限的创建对象,取而代之的是内部维护了一个对象池,当请求来时,从对象池中获取,当请求处理完毕后,对象也不会被销毁,而是再次放回对象池中

我们可以为这三种工厂声明公共的接口:IObjectFactory,这是非常有必要的,方便在运行时根据需求动态的切换不同工厂:

public interface IObjectFactory
{
    object AcquireObject(string className);
    object AcquireObject(Type type);
    object AcquireObject<TInstance>() where TInstance : class, new();
    void ReleaseObject(object obj);
}

这个接口功能很简单,通过统一的入口对对象进行创建与销毁的管理。

Singleton Factory

有了统一的工厂的接口之后,接下来就是去实现对应的工厂了,第一个要实现的就是 Singleton Factory:

public class SingletonObjectFactory:IObjectFactory
{
    /// <summary>
    /// 共享的字典,不会因为不同的SingletonObjectFactory对象返回不唯一的实例对象
    /// </summary>
    private static Dictionary<Type,object> _cachedObjects = null;
    private static readonly object _lock=new object();
    private Dictionary<Type, object> CachedObjects
    {
        get
        {
            lock (_lock)
            {
                if (_cachedObjects==null)
                {
                    _cachedObjects=new Dictionary<Type, object>();
                }
                return _cachedObjects;
            }
        }
    }

    //...省略部分代码...

    public object AcquireObject<TInstance>() where TInstance:class,new()
    {
        var type = typeof(TInstance);
        if (CachedObjects.ContainsKey(type))
        {
            return CachedObjects[type];
        }
        lock (_lock)
        {
            var instance=new TInstance();
            CachedObjects.Add(type, instance);
            return CachedObjects[type];
        }
    }

}

上述代码中,我们需要定义一个全局的字典,用来存储所有的单例,值得注意的是,CachedObjects 字典是一个 static 类型,这表明这是一个共享的字典,不会因为不同的SingletonObjectFactory对象返回不唯一的实例对象。

还有一点,单例模式最好考虑一下多线程并发问题,虽然这是一个 『伪』 需求,毕竟Unity 3D是个单线程应用程序,但 uMVVM 框架还是考虑了多线程并发的问题,使用 lock 关键字,它必须是一个 static 类型,保证 lock 了同一个对象。

Transient Factory

Transient Factory 是最容易实现的工厂,不用考虑多线程并发问题,也不用考虑Pool,对每一次请求返回一个不同的对象:

public class TransientObjectFactory : IObjectFactory
{
    //...省略部分代码...

    public object AcquireObject<TInstance>() where TInstance : class, new()
    {
        var instance = new TInstance();
        return instance;
    }

}

Pool Factory

Pool Factory 相对来说是比较复杂的工厂,它对 Transient Factory 进行了升级——创建实例前先去Pool中看看是否有未被使用的对象,有的话,那么直接取出返回,如果没有则向Pool中添加一个。

Pool的实现有两种形式,一种是内置了诸多对象,还有一种是初始时是一个空的池,然后再往里面添加对象。第一种效率更高,直接从池里面拿,而第二种更省内存空间,类似于懒加载,uMVVM 的对象池技术使用第二种模式。

public class PoolObjectFactory : IObjectFactory
{
    /// <summary>
    /// 封装的PoolData
    /// </summary>
    private class PoolData
    {
        public bool InUse { get; set; }
        public object Obj { get; set; }
    }

    private readonly List<PoolData> _pool;
    private readonly int _max;
    /// <summary>
    /// 如果超过了容器大小,是否限制
    /// </summary>
    private readonly bool _limit;

    public PoolObjectFactory(int max, bool limit)
    {
        _max = max;
        _limit = limit;
        _pool = new List<PoolData>();
    }

    private PoolData GetPoolData(object obj)
    {
        lock (_pool)
        {
            for (var i = 0; i < _pool.Count; i++)
            {
                var p = _pool[i];
                if (p.Obj == obj)
                {
                    return p;
                }
            }
        }
        return null;
    }
    /// <summary>
    /// 获取对象池中的真正对象
    /// </summary>
    /// <param name="type"></param>
    /// <returns></returns>
    private object GetObject(Type type)
    {
        lock (_pool)
        {
            if (_pool.Count > 0)
            {
                if (_pool[0].Obj.GetType() != type)
                {
                    throw new Exception(string.Format("the Pool Factory only for Type :{0}", _pool[0].Obj.GetType().Name));
                }
            }

            for (var i = 0; i < _pool.Count; i++)
            {
                var p = _pool[i];
                if (!p.InUse)
                {
                    p.InUse = true;
                    return p.Obj;
                }
            }


            if (_pool.Count >= _max && _limit)
            {
                throw new Exception("max limit is arrived.");
            }

            object obj = Activator.CreateInstance(type, false);
            var p1 = new PoolData
            {
                InUse = true,
                Obj = obj
            };
            _pool.Add(p1);
            return obj;
        }
     }

    private void PutObject(object obj)
    {
        var p = GetPoolData(obj);
        if (p != null)
        {
            p.InUse = false;
        }
    }

    public object AcquireObject(Type type)
    {
        return GetObject(type);
    }

    public void ReleaseObject(object obj)
    {
        if (_pool.Count > _max)
        {
            if (obj is IDisposable)
            {
                ((IDisposable)obj).Dispose();
            }
            var p = GetPoolData(obj);
            lock (_pool)
            {
                _pool.Remove(p);
            }
            return;
        }
        PutObject(obj);
    }
}

上述的代码通过构造函数的 max 决定Pool的大小,limit 参数表示超过Pool容量时,是否可以再继续往Pool中添加数据。方法 GetObject 是最核心的方法,逻辑非常简单,获取对象之前先判断Pool中是否有未被使用的对象,如果有,则返回,如果没有,则根据 limit 参数再决定是否可以往Pool中添加数据。

小结

工厂模式是最常见的设计模式,根据工厂的类型可以获取不同形式的数据对象,比如单例数据、临时数据、亦或是对象池数据。这一章的工厂模式很重要,也是对下一篇对象的注入『Inject』做准备,故称之为理念先行。
源代码托管在Github上,点击此了解

88x31.png
本博客为 木宛城主原创,基于 Creative Commons Attribution 2.5 China Mainland License发布,欢迎转载,演绎或用于商业目的,但是必须保留本文的署名 木宛城主(包含链接)。如您有任何疑问或者授权方面的协商,请给我留言。

本文转自木宛城主博客园博客,原文链接:http://www.cnblogs.com/OceanEyes/p/factory_pattern.html,如需转载请自行联系原作者
目录
相关文章
|
13天前
|
设计模式 Java API
Java 可扩展 API 设计:打造灵活的应用架构
【4月更文挑战第27天】设计可扩展的 API 是构建灵活、易于维护的应用程序架构的关键。Java 提供了丰富的工具和技术来实现这一目标,使开发者能够构建具有高度可扩展性的应用程序。
36 4
|
1天前
|
运维 Cloud Native 持续交付
构建未来:云原生架构在现代企业中的应用与挑战
【5月更文挑战第9天】 随着数字化转型的浪潮席卷全球,企业正迅速采纳云原生技术以实现敏捷性、可扩展性和弹性。本文深入探讨了云原生架构的关键组件,包括容器化、微服务、持续集成/持续部署(CI/CD)和DevOps文化,并分析了这些技术如何帮助企业加速产品上市时间,提高运营效率,并最终实现业务目标。同时,文章也识别了企业在采纳云原生实践中可能面临的挑战,如安全性考量、团队技能提升和复杂的网络管理,并提出了相应的解决方案和最佳实践。
|
4天前
|
监控 负载均衡 API
微服务架构在现代企业中的应用与挑战
微服务架构已成为现代企业构建灵活且可扩展软件系统的首选。然而,随着其应用的普及,企业也面临着一系列新的挑战。本篇文章将探讨微服务架构的优势、实施时遇到的问题以及解决这些问题的策略。
|
4天前
|
Kubernetes Cloud Native 持续交付
构建高效云原生应用:Kubernetes与微服务架构的融合
【5月更文挑战第6天】 在数字化转型的浪潮中,企业正迅速采纳云原生技术以实现敏捷性、可扩展性和弹性。本文深入探讨了如何利用Kubernetes这一领先的容器编排平台,结合微服务架构,构建和维护高效、可伸缩的云原生应用。通过分析现代软件设计原则和最佳实践,我们提出了一个综合指南,旨在帮助开发者和系统架构师优化云资源配置,提高部署流程的自动化水平,并确保系统的高可用性。
27 1
|
9天前
|
Cloud Native 安全 持续交付
构建未来:云原生架构在现代企业中的应用与挑战
【5月更文挑战第1天】 随着数字化转型的深入,云原生技术以其灵活性、可扩展性和敏捷性成为现代企业IT架构的核心。本文将探讨云原生架构的关键组件,包括容器化、微服务、持续集成/持续部署(CI/CD)以及DevOps实践,并分析它们如何共同塑造企业的运营模式。同时,文章还将讨论在采纳云原生过程中企业可能遇到的挑战,如安全性问题、技术复杂性以及组织文化的转变,并提出应对策略。
27 8
|
10天前
|
前端开发 JavaScript 安全
【TypeScript技术专栏】TypeScript在微前端架构中的应用
【4月更文挑战第30天】微前端架构通过拆分应用提升开发效率和降低维护成本,TypeScript作为静态类型语言,以其类型安全、代码智能提示和重构支持强化这一架构。在实践中,TypeScript定义公共接口确保跨微前端通信一致性,用于编写微前端以保证代码质量,且能无缝集成到构建流程中。在微前端架构中,TypeScript是保障正确性和可维护性的有力工具。
|
11天前
|
Cloud Native Devops 持续交付
构建未来应用:云原生架构在现代企业中的实践与挑战
【4月更文挑战第29天】 随着数字化转型的加速,企业正迅速转向云计算以支撑其业务敏捷性和创新。云原生技术,作为推动这一转型的关键因素,正在重新定义软件开发和运维模式。本文将深入探讨云原生架构的核心组件,包括容器化、微服务、持续集成/持续部署(CI/CD)以及DevOps文化,并分析这些技术如何帮助企业实现弹性、可扩展和高效的应用部署。同时,我们将讨论在采纳云原生实践中所面临的挑战,包括安全性、治理和人才缺口等问题。
|
11天前
|
消息中间件 PHP 数据库
【PHP开发专栏】PHP在微服务架构中的应用
【4月更文挑战第29天】微服务架构将大型应用拆分成独立小服务,PHP在其中可作为API网关、微服务提供者,参与服务发现、消息队列处理和事件驱动。最佳实践包括选择合适PHP框架、使用容器化技术、定义服务契约、采用分布式缓存、实现服务发现、监控和日志收集、优化数据库设计以及注重安全性。遵循这些实践,PHP开发者能构建高效、可扩展的微服务应用。
|
11天前
|
Cloud Native Devops 持续交付
构建未来:云原生架构在现代企业中的应用与挑战
【4月更文挑战第29天】 随着数字化转型的不断深入,企业的IT架构正经历着根本性的变革。云原生技术以其独特的弹性、可扩展性和敏捷性成为这一转型的关键驱动力。本文将探讨云原生架构的核心组件,包括容器化、微服务、持续集成/持续部署(CI/CD)以及DevOps实践,并分析这些技术如何帮助企业实现快速迭代和高效运营。同时,我们也将识别在采纳云原生技术过程中可能遇到的挑战,并提出相应的解决策略。通过实际案例分析,本文旨在为决策者提供实施云原生架构的洞见,以加速其业务创新和市场响应速度。
|
11天前
|
Cloud Native 安全 Devops
构建未来:云原生架构在现代企业中的应用与挑战
【4月更文挑战第29天】 随着数字化转型的不断深入,云原生架构已成为支撑企业敏捷性、可扩展性和创新能力的关键。本文将深入探讨云原生技术的核心组件,包括容器化、微服务、持续集成/持续部署(CI/CD)和DevOps文化,并分析其在不断变化的商业环境中实现快速迭代和资源优化的能力。同时,文章还将讨论企业在采纳云原生架构时面临的挑战,如技术选型、团队技能培养、安全性考虑及成本管理,并提出相应的解决策略。