svn-gvsig-desktop / branches / F2 / extensions / extJCRS / install / IzPack / src / lib / com / izforge / izpack / util / doc-files / TargetFactory.html @ 20036
History | View | Annotate | Download (3.7 KB)
1 |
<HTML>
|
---|---|
2 |
<HEAD>
|
3 |
<TITLE>Target Factory</TITLE> |
4 |
</HEAD>
|
5 |
<BODY>
|
6 |
<H2>How to use the TargetFactory</H2> |
7 |
By <font color=0000FF><i>Elmar Grom</i></font> |
8 |
<br><br> |
9 |
Here is a simple approach that you can use to automatically instantiate |
10 |
flavors of your class that are tailored to a specific operating system. |
11 |
If necessary you can even have different versions for different flavors |
12 |
of an operating system, such as Windows-NT. |
13 |
<br><br> |
14 |
Implement your API with the class name that you would like to use. The |
15 |
API can be implemented as interface, a partially or completely abastact |
16 |
class or a complete class implementation. The choice is your's and |
17 |
primarily depends your specific needs. However, it seems likely that in |
18 |
most cases it will be necessary to have a default implementation that |
19 |
can be instantiated if an appropriate flavor does not exist for some |
20 |
reason. One situation might be that a special version is not needed for |
21 |
all the different OS/OS-Flavor combinations but only for one or two |
22 |
cases. For all other cases the default implementation might work just |
23 |
fine. Another reason would be that an installation is attempted on an OS |
24 |
that is unknown or is not listed and as a fallback position a default |
25 |
implementation of the class should be available. For the following I |
26 |
assume that a complete implementation is used. |
27 |
<br><br> |
28 |
In the next step you need to derive one class for each of the different |
29 |
flavors you want to support with specific implementations. All of these |
30 |
classes must be contained in the same package as the base class and must |
31 |
follow a prescribed naming convention. Name prefixes are defined for a |
32 |
number of operating systems and operating system flavores. Please review |
33 |
the class documentation for <code>TargetFactory</code> for a a complete |
34 |
list of these prefixes. |
35 |
<br><br> |
36 |
Let's assume you have a class called <code>MyClass</code> in the package |
37 |
<code>com.izforge.izpack.installer</code>. This class contains your |
38 |
default implementation. For some reason you need modified functionality |
39 |
for Mac OS X. You would now implement the class |
40 |
<code>Mac_X_MyClass</code> which is extending <code>MyClass</code> and |
41 |
implements the necessary differences. This is all you need to do on the |
42 |
implementation end. |
43 |
<br><br> |
44 |
To get the correct instance based on the OS, simply call |
45 |
<code>makeObject()</code>. This example illustrates the call:<br> |
46 |
<PRE>
|
47 |
<font size=2 color=000000>TargetFactory.<b>getInstance</b> ().<b>makeObject</b> (</font><font size=2 color=FF0000>"com.izforge.izpack.installer.MyClass"</font><font size=2 color=000000>);</font> |
48 |
</PRE>
|
49 |
This call will return an instance of the proper flavor, without worry |
50 |
about the OS on your part. More specifically, you will recive an |
51 |
instance of <code>MyClass</code> on all operating systems, except on Mac |
52 |
OS X, in which case you will receive an instance of |
53 |
<code>Mac_X_MyClass</code>. To make this work, |
54 |
<code>TargetFactory</code> will automatically map the correct name and |
55 |
create an instance for you. |
56 |
<H3>The Constructor</H3> |
57 |
There is one drawback to this implementation that you must be aware of. |
58 |
Because of the way how instances are created, each class must have a |
59 |
default constructor. Of course this is done either by not implementing a |
60 |
constructor or by implementing a constructor without parameters (this |
61 |
must not be private). This constructor will be used when instances are |
62 |
created. As a result, you can not pass parameters to the constructor. |
63 |
<br><br> |
64 |
If you need to create instances that perform initial operations based on |
65 |
a set of parameters, I recommend the following approach. Instead of a |
66 |
constructor implement a method called <code>initialize()</code>. Call |
67 |
<code>makeObject()</code> to get your instance and then call |
68 |
<code>initialize()</code> with your parameters before using that object. |
69 |
</BODY>
|
70 |
</HTML>
|