ch03.htm

corba比较入门级的介绍详细间接了corba访问发布各种细节。

are omitted). The examples get ahead of themselves somewhat by using the interface
construct here; interfaces are described later in this chapter.
<H3><A NAME="Heading8"></A><FONT COLOR="#000077">Coupling and Cohesion</FONT></H3>
<P><B>New Term: </B>So, now that you have the ability to group interfaces together,
how do you decide which interfaces to group together? This is really a question of
system design and would be best answered in a text dedicated to that subject. (There
are plenty of excellent books available on the subject of object-oriented analysis
and design.) However, an overall guideline is that a good design generally exhibits
two attributes: <I>loose</I> <I>coupling</I> and <I>tight</I> <I>cohesion.</I> The
first means that components in separate modules are not tightly integrated with each
other; an application using components in one module generally need not know about
components in another module. (Of course, there is often some overlap between modules
for various reasons, such as the need to share data between modules or to facilitate
common functionality between modules.) When there is little or no dependency between
components, they are said to be loosely<I> </I>coupled<I>.</I></P>
<P>On the other hand, within a single module it is advantageous for a design to achieve
tight cohesion. This means that interfaces within the module are tightly integrated
with each other. For example, a module called InternalCombustionEngine might contain
interfaces such as CylinderHead, TimingChain, Crankshaft, Piston, and many others.
It is difficult to describe the purpose of one of these components without referring
to the others; hence, one might say that the components are tightly cohesive. By
way of comparison, you would probably find very little in common between the components
of InternalCombustionEngine and, for instance, AudioSystem; InternalCombustionEngine
components such as OilFilter and SparkPlug are loosely coupled to AudioSystem components
such as CompactDiscPlayer and Subwoofer.</P>
<P>Figure 3.1 illustrates the concepts of coupling and cohesion; note that there
are many relationships between components within the same module, whereas there are
few relationships between components within separate modules. The figure also illustrates
the advantage of loose coupling between modules: Imagine if, when you installed a
new CD player in your car, you had to change the spark plugs and replace your timing
chain! Loose coupling of components reduces the possibility that changes to one component
will require changes to another. <BR>
<BR>
<A HREF="javascript:popUp('01.jpg')"><B>Figure 3.1.</B></A> <I>Coupling and cohesion.</I>
<H2><A NAME="Heading9"></A><FONT COLOR="#000077">Primitive Types</FONT></H2>
<P>Like most programming languages, IDL features a variety of primitive types (which
can then be combined into aggregate types). These types store simple values such
as integral numbers, floating point numbers, character strings, and so on.
<H3><A NAME="Heading10"></A><FONT COLOR="#000077">void</FONT></H3>
<P>The IDL void type is analogous to the void type of C, C++, and Java. It is pointless
to have a variable of type void, but the type is useful for methods that don't return
any value.
<H3><A NAME="Heading11"></A><FONT COLOR="#000077">boolean</FONT></H3>
<P>The IDL boolean type, as its name suggests, stores a Boolean value. IDL defines
two boolean constants, true and false, which have obvious meanings. Depending on
the programming language used, the IDL boolean type can map to an integral type (such
as C/C++'s short) or to the language's native Boolean type (as is the case with Java).</P>
<PRE><FONT COLOR="#0066FF">boolean aBoolean;
</FONT></PRE>
<H3><A NAME="Heading12"></A><FONT COLOR="#000077">char and wchar</FONT></H3>
<P>The char type in IDL, analogous to the char type in C, C++, and Java, stores a
single character value. As expected, it maps directly to the char type in these languages.
The char data type is an 8-bit quantity.</P>
<PRE><FONT COLOR="#0066FF">char aChar;
</FONT></PRE>
<P>In version 2.1, CORBA added the wchar, or wide character type, which has an implementation-dependent
width (which is likely to be 16 bits, but you might want to consult with your ORB
documentation).
<H3><A NAME="Heading13"></A><FONT COLOR="#000077">Floating Point Types</FONT></H3>
<P>IDL defines a number of types to represent floating point values; these are already
familiar to most developers.
<H4><FONT COLOR="#000077">float</FONT></H4>
<P>The IDL float type represents an IEEE single-precision floating point value. Again,
it is analogous to the C, C++, and Java type of the same name.</P>
<PRE><FONT COLOR="#0066FF">float aFloat;
</FONT></PRE>
<H4><FONT COLOR="#000077">double and long double</FONT></H4>
<P>The double type represents an IEEE double-precision floating point value. Not
surprisingly, it corresponds to the familiar double type of a number of languages.</P>
<PRE><FONT COLOR="#0066FF">double aDouble;
</FONT></PRE>
<P>The long double type, introduced in CORBA 2.1, represents an IEEE double-extended
floating point value, having an exponent of at least 15 bits and a signed fraction
of at least 64 bits.
<H3><A NAME="Heading14"></A><FONT COLOR="#000077">Integer Types</FONT></H3>
<P>IDL also defines a number of integral numeric types. Again, most developers will
recognize these. Unlike most familiar programming languages, though, IDL doesn't
define a plain int type, only short and long integer types.
<H4><FONT COLOR="#000077">long and long long</FONT></H4>
<P>The IDL long type represents a 32-bit signed quantity (with a range of -2<SUP>31</SUP>..2<SUP>31</SUP>-1),
like C/C++'s int (on most platforms) and Java's int (on all platforms, because Java,
unlike C/C++, explicitly specifies the size of int).</P>
<PRE><FONT COLOR="#0066FF">long aLong;
</FONT></PRE>
<P>In CORBA 2.1, the long long type was added, which is a 64-bit signed quantity
(with a range of -2<SUP>63</SUP>..2<SUP>63</SUP>-1).
<H4><FONT COLOR="#000077">unsigned long and unsigned long long</FONT></H4>
<P>The unsigned long type in IDL is an unsigned version of the long type; its range
is 0..2<SUP>32</SUP>-1.</P>
<PRE><FONT COLOR="#0066FF">unsigned long anUnsignedLong;
</FONT></PRE>
<P>CORBA 2.1 added the unsigned long long type, which is a 64-bit unsigned quantity
with a range of 0..2<SUP>64</SUP>-1.
<H4><FONT COLOR="#000077">short</FONT></H4>
<P>The short type represents a 16-bit signed quantity, like C/C++'s short or short
int (again, on most platforms) and Java's short. Its range is -2<SUP>15</SUP>..2<SUP>15</SUP>-1.</P>
<PRE><FONT COLOR="#0066FF">short aShort;
</FONT></PRE>
<H4><FONT COLOR="#000077">unsigned short</FONT></H4>
<P>The unsigned short type, as expected, is the unsigned version of short, with a
range of 0..216-1.</P>
<PRE><FONT COLOR="#0066FF">unsigned short anUnsignedShort;
</FONT></PRE>
<H3><A NAME="Heading15"></A><FONT COLOR="#000077">octet</FONT></H3>
<P>The octet type is an 8-bit quantity that is not translated in any way during transmission.
This type has no direct counterpart in C and C++, although the char or unsigned char
types are often used to represent this type of value. Java, of course, has the byte
type, which is similar.</P>
<PRE><FONT COLOR="#0066FF">octet anOctet;
</FONT></PRE>
<H3><A NAME="Heading16"></A><FONT COLOR="#000077">string</FONT></H3>
<P>The string type represents a string of characters, similar to C++'s Cstring and
Java's String class. C has no direct counterpart (because there is no &quot;true&quot;
string type in C); character arrays are used instead. IDL supports both fixed- and
variable-length strings.</P>
<PRE><FONT COLOR="#0066FF">string aFixedLengthString[20];
string aVariableLengthString;
</FONT></PRE>
<H3><A NAME="Heading17"></A><FONT COLOR="#000077">The const Modifier</FONT></H3>
<P>In addition to these standard types, IDL, like C and C++, also allows constant
values to be specified by using the const modifier. const values are useful for values
that should not change, such as physical constants such as <I>pi</I> or <I>c.</I>
The scope of a const value, like any value, is that of its enclosing interface or
module.</P>
<PRE><FONT COLOR="#0066FF">const float aFloatConstant = 3.1415926535897932384;
const long aLongConstant = 12345;
const string aStringConstant = &quot;Ain't IDL great?&quot;;
</FONT></PRE>
<H2><A NAME="Heading18"></A><FONT COLOR="#000077">Constructed Types</FONT></H2>
<P>Constructed types, which combine other types, enable the creation of user-defined
types. Perhaps the most useful of these constructs is the interface, which defines
the services provided by your application objects. Because IDL is, after all, the
Interface Definition Language, it seems fitting that interfaces should comprise the
bulk of IDL source code.
<H3><A NAME="Heading19"></A><FONT COLOR="#000077">The Enumerated Type</FONT></H3>
<P>The enumerated type, enum, allows the creation of types that can hold one of a
set of predefined values specified by the enum. Although the identifiers in the enumeration
comprise an ordered list, IDL does not specify the ordinal numbering for the identifiers.
Therefore, comparing enum values to integral values might not be safe, and would
almost certainly not be portable across languages. C and C++ also have an enumerated
type that works similarly. An example of the enum type appears in Listing 3.3.
<H4><FONT COLOR="#000077">Listing 3.3. enum example.</FONT></H4>
<PRE><FONT COLOR="#0066FF">1: enum DaysOfWeek {
2:     Sunday,
3:     Monday,
4:     Tuesday,
5:     Wednesday,
6:     Thursday,
7:     Friday,
8:     Saturday
9: };</FONT></PRE>
<H3><A NAME="Heading20"></A><FONT COLOR="#000077">The Structure Type</FONT></H3>
<P>IDL provides a structure type--struct--that contains, as in C and C++, any number
of member values of disparate types (even other structs). structs are especially
useful in IDL because, unlike CORBA objects (which are represented by interfaces),
structs are passed by value rather than by reference. In other words, when a struct
is passed to a remote object, a copy of that struct's values is created and marshaled
to the remote object. An example of the struct type appears in Listing 3.4.
<H4><FONT COLOR="#000077">Listing 3.4. struct example.</FONT></H4>
<PRE><FONT COLOR="#0066FF">1: struct DateStruct {
2:     short year,
3:     short month,
4:     short day,
5:     short hour,
6:     short minute,
7:     short second,
8:     long microsecond
9: };</FONT></PRE>
<H3><A NAME="Heading21"></A><FONT COLOR="#000077">The union Type</FONT></H3>
<P>The IDL union type, like a struct, represents values of different types. The IDL
union type will appear somewhat odd to C and C++ programmers, resembling something
of a cross between a C/C++ union and a case statement, but Pascal programmers should
recognize the format. An example of a union definition appears in Listing 3.5.
<H4><FONT COLOR="#000077">Listing 3.5. union example.</FONT></H4>
<PRE><FONT COLOR="#0066FF">1: union MultiplePersonalities switch(long) {
2:     case 1:
3:         short myShortPersonality;
4:     case 2:
5:         double myDoublePersonality;
6:     case 3:
7:     default:
8:         string myStringPersonality;
9: }; </FONT></PRE>
<P>In the example in Listing 3.5, a variable of type MultiplePersonalities might
have either a short value, a double value, or a string value, depending on the value
of the parameter when the union is used in a method call. (The parameter is known
as a <I>discriminator.</I>)</P>
<P><B>New Term: </B>A <I>discriminator,</I> as used in an IDL union, is a parameter
that determines the value used by the union. In the example in Listing 3.5, a long
was used for the discriminator; other types can be used also, including long, long
long, short, unsigned long, unsigned long long, unsigned short, char, boolean, or
enum. The constant values in the case statements must match the discriminator's type.


<BLOCKQUOTE>
	<P>
<HR>
<B>Note:</B>In practice, IDL unions are rarely useful. Whereas the traditional C
	union might find a use in optimization of native C code, unions almost never appear
	in distributed applications. Behavior of objects is usually better abstracted through
	the use of interfaces. However, should the need for a union arise, IDL provides this
	type, just in case. 
<HR>


</BLOCKQUOTE>

<H3><A NAME="Heading22"></A><FONT COLOR="#000077">The interface Type</FONT></H3>
<P>The interface type is by far the most versatile of IDL data types. The interface
describes the services provided by a CORBA object. These services appear in the form
of operations (or methods)<I>,</I> resembling methods in object-oriented languages
like C++ and Java. The difference, again, is that IDL is used only to specify the
interfaces of these methods, whereas languages like Java and C++ are used to specify
interfaces and (usually) provide implementations for those interfaces' methods.</P>
<P>The IDL interface type is very much like the Java interface type because neither
provides an implementation for the methods defined. (However, a major difference
is that IDL interfaces can contain attributes, whereas Java interfaces don't.) C++,
on the other hand, has no direct counterpart to IDL's interface, although it is common
for C++ applications to use a header<I> </I>file to define the interface of a class.
An IDL interface definition can thus be compared to a C++ header file containing
a class definition. Also, a C++ class whose methods are all pure virtual can be considered
analogous to the IDL interface.</P>
<P>Like a Java or C++ class, an IDL interface can contain attributes (also commonly
known as member<I> </I>variables) and operations (which, again, you may know as methods
or member functions). Like Java's interface, all methods defined within an IDL interface
are public--they can be called by any other object having a reference to the interface's
implementation object. Finally, because IDL interfaces usually describe remote objects,
IDL also provides some additional modifiers to further describe the interface and
its members. For example, methods can be declared as oneway; arguments to methods
can be declared as in, out, or inout; and attributes can be declared as readonly.