MDN may have intermittent access issues April 18 13:00 - April 19 01:00 UTC. See whistlepig.mozilla.org for all notifications.

mozilla

Comparar revisiones

Un vistazo de XPCOM

Change Revisions

Revisión 276200:

Revisión 276200 de Maharba el

Revisión 276201:

Revisión 276201 de Maharba el

Título:
Un vistazo de XPCOM
Un vistazo de XPCOM
Enlace amigable (slug):
Creación_de_Componentes_XPCOM/Un_vistazo_de_XPCOM
Creación_de_Componentes_XPCOM/Un_vistazo_de_XPCOM
Etiquetas:
XPCOM, Todas_las_Categorías
XPCOM, Todas_las_Categorías
Contenido:

Revisión 276200
Revisión 276201
n419      Once code is broken up into components, client code typicaln419      Una vez que el código es dividido en componentes, el código
>ly uses the <code>new</code> operator to instantiate objects for > cliente típicamente usa el operador <code>new</code> para instan
>use:>ciar los objetos a usar:
n425      This pattern requires that the client knows something aboutn425      Este patrón requiere que el cliente sepa algo acerca del co
> the component, however-how big it is at the very least. The <i>f>mponente, al menos qué tan grande es. El <i>patrón de diseño fact
>actory design pattern</i> can be used to encapsulate object const>oría</i> puede usarse para encapsular la construcción de objetos.
>ruction. The goal of a factory is to create an object without exp> El objetivo principal de una factoría es crear un objeto sin mos
>osing clients to the implementation and initialization of this ob>trar a los clientes la implementación e inicialización de este ob
>ject. In the <code>SomeClass</code> example, the construction and>jeto. En el ejemplo <code>SomeClass</code> la construcción e inic
> initialization of <code>SomeClass</code>, which implements the <>ialización de <code>SomeClass</code> que implementa la clase abst
>code>SomeInterface</code> abstract class, is contained within the>racta <code>SomeInterface</code>, es contenida dentro de la funci
> <code>New_SomeInterface</code> function, which follows the facto>ón <code>New_SomeInterface</code> que sigue el patrón de diseño f
>ry design pattern:>actoría:
426    </p>
427    <p>426    </p>
427    <p>
428      {{wiki.template('Block-title', [ "Encapsulating the Constru428      {{wiki.template('Block-title', [ "Encapsulación del Constru
>ctor" ])}}>ctor" ])}}
n433  // create the objectn433  // crea el objeto
n437  // init the objectn437  // inicializa el objeto
n444  // cast to the interfacen444  // referencia de la interfaz
t450      The factory is the class that actually manages the creationt450      La factoría es la clase que gestiona la creación de instanc
> of separate instances of a component for use. In XPCOM, factorie>ias separadas de un componente para su uso. En XPCOM, las factorí
>s are implementations of the <code>nsIFactory</code> interface, a>as son implementaciones de la interfaz <code>nsIFactory</code> y 
>nd they use a factory design pattern like the example above to ab>usan un patrón de diseño factoría como el ejemplo de arriba para 
>stract and encapsulate object construction and initialization.>abstraer y encapsular la construcción e inicialización del objeto
 >.
451    </p>
452    <p>451    </p>
453      The example in {{template.Anch("Encapsulating the Construct
>or")}} is a simple and stateless version of factories, but real w 
>orld programming isn't usually so simple, and in general factorie 
>s need to store state. At a minimum, the factory needs to preserv 
>e information about what objects it has created. When a factory m 
>anages instances of a class built in a dynamic shared library, fo 
>r example, it needs to know when it can unload the library. When  
>the factory preserves state, you can ask if there are outstanding 
> references and find out if the factory created any objects. 
454    </p>452    <p>
453      El ejemplo en {{template.Anch("Encapsulación del Constructo
 >r")}} es una versión simple sin estado de las factorías, pero pro
 >gramarlo en el mundo real usualmente no es tan simple y en genera
 >l las factorías necesitan guardar un estado. La factoría necesita
 >, por lo menos preservar información de qué objetos ha creado. Cu
 >ando una factoría gestiona instancias de una clase contenida en u
 >n biblioteca dinámica compartida, por ejemplo, necesita saber cua
 >ndo puede descargar la biblioteca. Cuando la factoría preserva un
 > estado, puedes preguntarle si hay referencias esperando y saber 
 >si la factoría creó objetos.
455    <p>454    </p>
456      Another state that a factory can save is whether or not an 
>object is a <i>singleton</i>. For example, if a factory creates a 
>n object that is supposed to be a singleton, then subsequent call 
>s to the factory for the object should return the same object. Th 
>ough there are tools and better ways to handle singletons (which  
>we'll discuss when we talk about the <code>nsIServiceManager</cod 
>e>), a developer may want to use this information to ensure that  
>only one singleton object can exist despite what the callers do. 
457    </p>455    <p>
456      Otro estado que puede guardar una factoría es si un objeto 
 >es o no <i>singleton</i>. Por ejemplo, si una factoría crea un ob
 >jeto que se supone debe ser singleton, entonces las llamadas subs
 >ecuentes a la factoría por el objeto deben regresar el mismo obje
 >to. Aunque que hay herramientas y mejores formas de gestionar un 
 >singleton (lo que discutiremos cuando hablemos del <code>nsIServi
 >ceManager</code>), un desarrollador tal vez quiera usar esta info
 >rmación para asegurarse de que sólo puede existir un objeto singl
 >eton sin importar lo que hagan los clientes.
458    <p>457    </p>
459      The requirements of a factory class can be handled in a str458    <p>
>ictly functional way, with state being held by global variables,  
>but there are benefits to using classes for factories. When you u 
>se a class to implement the functionality of a factory, for examp 
>le, you derive from the <code>nsISupports</code> interface, which 
> allows you to manage the lifetime of the factory objects themsel 
>ves. This is important when you want to group sets of factories t 
>ogether and determine if they can be unloaded. Another benefit of 
> using the <code>nsISupports</code> interface is that you can sup 
>port other interfaces as they are introduced. As we'll show when  
>we discuss <code>nsIClassInfo</code>, some factories support quer 
>ying information about the underlying implementation, such as wha 
>t language the object is written in, interfaces that the object s 
>upports, etc. This kind of "future-proofing" is a key advantage t 
>hat comes along with deriving from <code>nsISupports</code>. 
459      Los requerimientos de una clase factoría pueden gestionarse
 > de una manera estrictamente funcional con el estado guardado en 
 >variables globales, pero hay beneficios de usar clases para las f
 >actorías. Cuando usas una clase para implementar la funcionalidad
 > de una factoría, por ejemplo, derivas de la interfaz <code>nsISu
 >pports</code>, que te permite manejar el tiempo de vida de los ob
 >jetos de la factoría por sí mismos. Esto es importante cuando qui
 >eres agrupar conjuntos de factorías y determinar si pueden ser de
 >scargados. Otro beneficio de usar la interfaz <code>nsISupports</
 >code> es que puedes soportar otras interfaces al momento en que s
 >ean introducidas. Como mostraremos al discutir <code>nsIClassInfo
 ></code>, algunas factorías permiten pedir información acerca de l
 >a implementación que tienen debajo, como el lenguaje en el está e
 >scrito el objeto, las interfaces que soporta, etc. Este tipo de "
 >comprobación futura" es una ventaja clave que se obtiene al deriv
 >ar de <code>nsISupports</code>.

Volver al historial