|
[Dean Asmussen opined:] My suggestion was, if you are planning to support multiple servers, create a generic JAVA version that will run anywhere. After the base application has been tested and verified, start developing server-side programs specific to the platform to be supported. For example, use a control record that tells the application that it is talking to an AS/400, so use the toolbox stuff. Sounded good to me at the time, but the "purists" tended to disagree. Personally, I don't _WANT_ my stuff to run like it's on Windoze ;-)... ------------- The idea is sound, Dean. However, you don't have to go through the trouble of adding a control record. You can instead use a wonderful system call, System.getProperty("os.name"). I take advantage of that in my Splf2Pdf class to determine whether I can use the IFSFile streams instead of the standard Java streams. The best way to take advantage of that kind of call is to use a factory method whenever you create an object that varies based on implementation. You write your application to use a class called Item. All your normal methods, setters and getters, are all in the Item class. The application only sees objects of class Item. Under the covers, though, magic happens. Item declares any method that changes from implementation to implementation as virtual. Let's say the Item class uses native I/O to read a record on the AS/400, but SQL on other platforms. Okay, you simply declare a virtual method getData(). This, of course, makes Item an abstract class, but that's okay, because we actually define two subclasses: Item400 and ItemSql. Item400 defines the getRecord class using toolkit I/O, and ItemSql defines it using SQL. Both inherit all the other methods from Item. Okay, now instead of simply calling "new Item()" to create a new item, we execute Item item = Item.getItem(); The factory class getItem() determines which implementation we're on, and returns either Item400 or ItemSql. Then, when the application executes item.getData(), the JVM determines which version of getData() to execute. The beauty of this technique is that on, say, a non-AS/400 implementation, you never instantiate an object of type Item400, so the toolbox routines never get loaded! Ah, the wonderful world of objects... ================== Joe "Zappie" Pluta www.zappie.net/java "Where the AS/400 speaks Java... with an RPG accent" ================== +--- | This is the JAVA/400 Mailing List! | To submit a new message, send your mail to JAVA400-L@midrange.com. | To subscribe to this list send email to JAVA400-L-SUB@midrange.com. | To unsubscribe from this list send email to JAVA400-L-UNSUB@midrange.com. | Questions should be directed to the list owner/operator: david@midrange.com +---
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact copyright@midrange.com.
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.