mozilla

Comparar revisiones

Un vistazo de XPCOM

Change Revisions

Revisión 276199:

Revisión 276199 de Maharba el

Revisión 276200:

Revisión 276200 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 276199
Revisión 276200
nn418    <p>
419      Once code is broken up into components, client code typical
 >ly uses the <code>new</code> operator to instantiate objects for 
 >use:
420    </p>
421    <pre>
422SomeClass* component = new SomeClass();
423</pre>
424    <p>
425      This pattern requires that the client knows something about
 > the component, however-how big it is at the very least. The <i>f
 >actory design pattern</i> can be used to encapsulate object const
 >ruction. The goal of a factory is to create an object without exp
 >osing clients to the implementation and initialization of this ob
 >ject. In the <code>SomeClass</code> example, the construction and
 > initialization of <code>SomeClass</code>, which implements the <
 >code>SomeInterface</code> abstract class, is contained within the
 > <code>New_SomeInterface</code> function, which follows the facto
 >ry design pattern:
426    </p>
427    <p>
428      {{wiki.template('Block-title', [ "Encapsulating the Constru
 >ctor" ])}}
429    </p>
430    <pre>
431int New_SomeInterface(SomeInterface** ret)
432{
433  // create the object
434  SomeClass* out = new SomeClass();
435  if (!out) return -1;
436 
437  // init the object
438  if (out-&gt;Init() == FALSE)
439  {
440    delete out;
441    return -1;
442  }
443 
444  // cast to the interface
445  *ret = static_cast&lt;SomeInterface*&gt;(out);
446  return 0; 
447
448</pre>
449    <p>
450      The factory is the class that actually manages the creation
 > of separate instances of a component for use. In XPCOM, factorie
 >s are implementations of the <code>nsIFactory</code> interface, a
 >nd they use a factory design pattern like the example above to ab
 >stract and encapsulate object construction and initialization.
451    </p>
452    <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>
455    <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>
458    <p>
459      The requirements of a factory class can be handled in a str
 >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>.
460    </p>
tt464    <p>
465      An easy and powerful way to define an interface - indeed, a
 > requirement for defining interfaces in a cross-platform, languag
 >e neutral development environment - is to use an <i>interface def
 >inition language</i> (IDL). XPCOM uses its own variant of the COR
 >BA OMG Interface Definition Language (IDL) called XPIDL, which al
 >lows you to specify methods, attributes and constants of a given 
 >interface, and also to define interface inheritance.
466    </p>
467    <p>
468      There are some drawbacks to defining your interface using X
 >PIDL. There is no support for multiple inheritance, for one thing
 >. If you define a new interface, it cannot derive from more than 
 >one interface. Another limitation of interfaces in XPIDL is that 
 >method names must be unique. You can not have two methods with th
 >e same name that take different parameters, and the workaround - 
 >having multiple function names - isn't pretty:
469    </p>
470    <pre>
471void FooWithInt(in int x);
472void FooWithString(in string x);
473void FooWithURI(in nsIURI x);
474</pre>
475    <p>
476      However, these shortcomings pale in comparison to the funct
 >ionality gained by using XPIDL. XPIDL allows you to generate <i>t
 >ype libraries</i>, or typelibs, which are files with the extensio
 >n <i>.xpt</i>. The type library is a binary representation of an 
 >interface or interfaces. It provides programmatic control and acc
 >ess of the interface, which is crucial for interfaces used in the
 > non C++ world. When components are accessed from other languages
 >, as they can be in XPCOM, they use the binary type library to ac
 >cess the interface, learn what methods it supports, and call thos
 >e methods. This aspect of XPCOM is called <i>XPConnect</i>. XPCon
 >nect is the layer of XPCOM that provides access to XPCOM componen
 >ts from languages such as JavaScript. See <a href="es/Creating_XP
 >COM_Components/Using_XPCOM_Components#Connecting_to_Components_fr
 >om_the_Interface">Connecting to Components from the Interface</a>
 > for more information about XPConnect.
477    </p>
478    <p>
479      When a component is accessible from a language other than C
 >++, such as JavaScript, its interface is said to be "reflected" i
 >nto that language. Every reflected interface must have a correspo
 >nding type library. Currently you can write components in C, C++,
 > or JavaScript (and sometimes Python or Java, depending on the st
 >ate of the respective bindings), and there are efforts underway t
 >o build XPCOM bindings for Ruby and Perl as well.
480    </p>
481    <div class="side-note">
482      <p>
483        {{wiki.template('Block-title', [ "Writing Components in O
 >ther Languages" ])}}
484      </p>
485      <p>
486        Though you do not have access to some of the tools that X
 >PCOM provides for C++ developers (such as macros, templates, smar
 >t pointers, and others) when you create components in other langu
 >ages, you may be so comfortable with the language itself that you
 > can eschew C++ altogether and build, for example, Python-based X
 >PCOM components that can be used from JavaScript or vice versa.
487      </p>
488      <p>
489        See <a href="es/Creating_XPCOM_Components/Resources">Reso
 >urces</a> for more information about Python and other languages f
 >or which support has been added in XPCOM.
490      </p>
491    </div>
492    <p>
493      All of the public interfaces in XPCOM are defined using the
 > XPIDL syntax. Type libraries and C++ header files are generated 
 >from these IDL files, and the tool that generates these files is 
 >called the <i>xpidl compiler</i>. The section <a href="es/Creatin
 >g_XPCOM_Components/Starting_WebLock#Defining_the_WebLock_Interfac
 >e_in_XPIDL">Defining the WebLock Interface in XPIDL</a> describes
 > the XPIDL syntax in detail.
494    </p>

Volver al historial