GOF之享元模式

面向对象的代价:

面向对象很好的解决了系统抽象问题,同时在大多数情况下,也不会损及系统的性能。但是,在某些特殊的应用中,由于对象的数量太大,采用面向对象会给系统带来难以承受的内存开销。比如图形应用中的图元等对象、字处理应用中的字符对象等。

动机(Motivation)

采用纯粹对象方案的问题在于大量细粒度的对象会很快充斥在系统中,从而带来很高的运行时代价--主要指内存需求方面的代价。

如何在避免大量细粒度对象问题的同时,让外部客户程序仍然能够透明地使用面向对象的方式来进行操作?

意图(Intent)

运用共享技术有效的支持大量细粒度的对象。

结构(Structure)

Flyweight模式的几个要点:

面向对象很好的解决了抽象性的问题,但是作为一个运行在机器中的程序实体,我们需要考虑对象的代价问题。Flyweight模式主要解决面向对象的代价问题,一般不触及面向对象的抽象性问题。

Flyweight采用对象共享的做法来降低系统中对象的个数,从而降低细粒度对象给系统带来的内存压力。在具体实现方面,要注意对象状态的处理。

对象的数量太大从而导致对象内存开销太大--什么样的数量才算大?这需要我们仔细的根据具体情况进行评估,而不能凭空臆断。

时间: 2024-08-29 13:18:11

GOF之享元模式的相关文章

NET设计模式 第二部分 结构性模式(12):享元模式(Flyweight Pattern)

享元模式(Flyweight Pattern) ——.NET设计模式系列之十三 Terrylee,2006年3月 摘要:面向对象的思想很好地解决了抽象性的问题,一般也不会出现性能上的问题.但是在某些情况下,对象的数量可能会太多,从而导致了运行时的代价.那么我们如何去避免大量细粒度的对象,同时又不影响客户程序使用面向对象的方式进行操作? 本文试图通过一个简单的字符处理的例子,运用重构的手段,一步步带你走进Flyweight模式,在这个过程中我们一同思考.探索.权衡,通过比较而得出好的实现方式,而不

第11章 享元模式(Flyweight Pattern)

原文 第11章 享元模式(Flyweight Pattern) 概述:   面向对象的思想很好地解决了抽象性的问题,一般也不会出现性能上的问题.但是在某些情况下,对象的数量可能会太多,从而导致了运行时的代价.那么我们如何去避免大量细粒度的对象,同时又不影响客户程序使用面向对象的方式进行操作?享元模式j就可以让我们更好的复用我们内存中已存在的对象,降低系统创建对象实例的性能消耗 运用共享技术有效地支持大量细粒度的对象.[GOF <设计模式>] 结构图:   举例: 为了方便说清享元模式的核心,我

设计模式之享元模式(Flyweight)摘录

23种GOF设计模式一般分为三大类:创建型模式.结构型模式.行为模式. 创建型模式抽象了实例化过程,它们帮助一个系统独立于怎样创建.组合和表示它的那些对象.一个类创建型模式使用继承改变被实例化的类,而一个对象创建型模式将实例化托付给还有一个对象.创建型模式有两个不断出现的主旋律.第一,它们都将关于该系统使用哪些详细的类的信息封装起来.第二,它们隐藏了这些类的实例是怎样被创建和放在一起的.整个系统关于这些对象所知道的是由抽象类所定义的接口.因此,创建型模式在什么被创建,谁创建它,它是怎样被创建的,

【Unity3D与23种设计模式】享元模式(Flyweight)

GoF中定义: "使用共享的方式,让一大群小规模对象能更有效地运行" 享元模式一般应用在游戏角色属性设置上 游戏策划需要通过"公式计算"或者"实际测试"等方式找出最佳的游戏属性 因此,在游戏系统中建立一个管理方式来建立和存储属性信息就显得尤为重要 对象中那些只能读取不能写入的共享部分被称为"内在状态" 如:最大生命(MaxHP).移动速度(MoveSpeed)等属性 还有不能被共享的部分,被称为"外部状态"

.NET设计模式(13):享元模式(Flyweight Pattern)(转)

摘要:面向对象的思想很好地解决了抽象性的问题,一般也不会出现性能上的问题.但是在某些情况下,对象的数量可能会太多,从而导致了运行时的代价.那么我们如何去避免大量细粒度的对象,同时又不影响客户程序使用面向对象的方式进行操作? 本文试图通过一个简单的字符处理的例子,运用重构的手段,一步步带你走进Flyweight模式,在这个过程中我们一同思考.探索.权衡,通过比较而得出好的实现方式,而不是给你最终的一个完美解决方案. 主要内容: 1.  Flyweight模式解说 2..NET中的Flyweight

设计模式11: Flyweight 享元模式(结构型模式)

Flyweight 享元模式(结构型模式) 面向对象的代价 面向对象很好的解决了系统抽象性的问题,同时在大多数情况下也不会损及系统的性能.但是,在某些特殊应用中,由于对象的数量太大,采用面向对象会给系统带来难以承受的内存开销.比如图形应用中的图元等对象.字处理应用中的字符对象等. 动机(Motivation) 采用纯粹对象方案的问题在于大量细粒度的对象会很快充斥在系统中,而带来很高的运行代价——主要指内存需求方面的代价. 如何避免大量细粒度对象问题的同时,让外部客户程序仍然能够透明地使用面向对象

设计模式---对象性能模式之享元模式(Flyweight)

一:概念 通过与其他类似对象共享数据来减少内存占用 如果一个应用程序使用了太多的对象, 就会造成很大的存储开销. 特别是对于大量轻量级 (细粒度)的对象,比如在文档编辑器的设计过程中,我们如果为每个字母创建一个对象的话,系统可能会因为大量的对象而造成存储开销的浪费.例如一个字母“a”在文档中出现了100000 次,而实际上我们可以让这一万个字母“a”共享一个对象,当然因为在不同的位置可能字母“a”有不同的显示效果(例如字体和大小等设置不同) ,在这种情况我们可以为将对象的状态分为“外部状态”和“

设计模式之享元模式(结构型)

模式定义 享元模式(Flyweight Pattern)就是通过共享技术实现大量细粒度对象的复用.享元模式是通过细粒度对象的共享,所以也可以说享元模式是一种轻量级模式.按照Gof模式分类,享元模式属于对象结构型模式. 模式解释 可以共享的内容称为内部状态(Intrinsic State),需要外部环境设置的不能共享的内容称为外部状态(Extrinsic State).享元模式需要创建一个享元工厂负责维护享元池(Flyweight Pool),享元池用于存储具有相同内部状态的享元对象. 享元模式中

享元模式(结构型)

思考问题:设计一个围棋游戏,模拟一个下棋动作,如何设计? 解答:很直接的,我们会设计一个棋盘类Chessboard,一个棋子类Chesspiece,每下一枚棋子时就new一个棋子对象(传入颜色.位置),然后将这些棋子装入到一个容器中. 这种简单粗暴的方式确实是解决了问题,但你会发现,棋子永远只有黑白色,棋子对象的函数都是一样的, 主要的变化只是(x,y)位置而已,那能不能单独把(x,y)独立出来让调用者管理(而非记录到棋子内部),让棋子对象变成一个可重用的对象呢?这样就可以避免产生大量棋子对象了