Buck Here are more ramblings of one who is struggling with the same questions: At 10:09 AM 12/1/1997 -0500, you wrote: >>> If we use OO to design our client properly, then the client has a clear, >>> well defined standard interface to the server. It is this interface which >>> makes the client application independent of the server platform. >> >>I gotta be honest, I don't see what OO design in the client has to do with >>the server's interface. What if the server was written by a maniac and the >>interface is cumbersome and confusing? > >The client interface cannot exist without the server interface. (I can't write the >client to use data queues and the server to use ODBC and "parameter" >files...) What's the benefit of writing a great OO client and not writing an >equally great server interface? (The "what-if" is a bit farfetched...) As I see it, the client should know diddly about data queues, ODBC, whatever. The client asks your server for the information it needs, and the _server_ knows the best way to get it for whatever backend you're dealing with. It sounds like you want _both_ the client and the server to retrieve data. I don't advocate this approach. Rather, separate function more—the client is essentially presentation, input, and some calculations (very simplistic I know); the server is a middleman that retrieves data from a database/backend machine and serves it to a requester, otherwise known as a client. A real-world analogy. You are a client of your local IGA or A&P. Would you go to the trouble of talking to the rancher or farmer that provides what the grocer sells? Usually not. You want to get a steak, you don't want to buy a side of beef and then cut your own steak out of it. You don't need to know the details of how the steak got there, just that the grocer (server) has been found reliable and trustworthy in the delivery of what you want. -snip- >>> To that end, we try to make our OO app as machine-independent on the client as >>> possible. Why bother designing all those classes, etc. only to have to re-write the >>> blasted things so they run on another client platform? Likewise, what's the point >>> writing an awesome OO system that can't talk to another server platform without >>> a re-write? In each case, we lose our prime goal of code re-use. Don't forget polymorphism, which, along with inheritance, gives the ability to have different methods of the same name and with different arguments. This can be the basis for multiple system access in a server—each additional platform is not a matter of having "to re-write the blasted things"—rather, a matter of adding to what already exists. -snip- >Re-compiled is one thing. I certainly don't expect my machine code to run >on multiple machines! I'm talking about re-use here. If I can simply(!) re-compile >my source to run on another platform, then I am reusing that application, >component, source, whatever. If I have to re-write, re-debug, re-test, re-document >and re-compile, then I'm not re-using my code, component, application, bean, whatever. >Re-compiling doesn't violate platform independence, re-writing does. Buck, you seem stuck on this "re-writing" thing. As far as I can tell, one of the primary tenets of OOP is to eliminate "re-writing". As I mentioned above, when new functionality is required, it is often "extending" rather that "re-writing". But this depends on an appropriate _design_ in the first place—a crucial aspect of OOP. >>Platform independance is an advantage of Java. It has nothing to do with the >>language being OO, but rather that it runs in a Virtual Machine. > >OK. You're talking about "byte-code", "P-code", "MI code", "object code" or whatever >the Java folk call their version of the interactive code interpreter. The fact that the >"object code" can physically execute on many hardware platforms doesn't mean >anything at all if that code calls a VM BAL program that will only run under MVS. > >A _very_ similar situation exists with REXX. REXX runs on OS/2, AS/400, VM and MVS. >This is great as long as I don't write any OS/2 specific code in my REXX proc and >then try to run it on my 400. It'll "run", but it won't work! > >OO=re-use. >Re-use=ability to execute application (after re-compile) on multiple machines and > obtaining the same results without re-writing the app. This is an inappropriate use of "re-use", IMO. This seems to me to define "portability" more than "re-use". >If my Java code talks to some AS/400 specific widget, then it's not portable. If it's >not portable then I can't very well re-use it, no matter that the byte code can be >interpreted by another hardware platform. True, but the operative phrase here is "my Java code". That is _not_ the same as the concept of the portability of Java, as I see it. -snip- >My fear about Java still centers around putting code, beans, whatever that >only work if they talk to an AS/400. Now, my much-vaunted Java independence >means only that I can pick any client platform to run on, as long as the server >is an AS/400... I gotta tell you that we need to talk to other boxes as well as >the /400. Even IBM has figured this out by now (NT on the IPCS, etc...) This has intrinsically _nothing_ to do with Java qua Java. Sun never promised to deliver what you're talking about, I think. Java is a _language_, and that's all. The output of its compiler, according to Sun specs, will be an object comprising so-called 'bytecodes', which can be interpreted (and sometimes just-in-time-compiled) by any JVM on any platform. As I see it, that is as far as the portability thing goes. This is much farther, IMO, than Smalltalk or C or C++ have got, although they all promise some kind of portability. In these latter languages, the portability is there, to some extent, in the source code. It does not extend to anything like an executable. You need separate compilers (or enough options on the one you use) for _each_ destination platform. With Java, you use one compiler, for all platforms. There's always a line separating platform-dependent and platform-independent parts of applications. With Java, the platform-dependent parts are implemented in the JVM. Now, I just read in _Core Java_, by Horstmann & Cornell (superb book, well-balanced, a few typos),, there's a concept in Java of a 'toolkit', which is something that gets at platform-specific data, for use in a Java app. There's a Toolkit class already. I found this idea helpful in thinking about the AS/400 Toolkit for Java. It's a set of tools to get at some AS/400-specific information. That's its purpose, to provide other, possibly more efficient, ways to get to data on an AS/400. Does this take away from the portability of Java? Not a whit, when we distinguish Java from _our use_ of Java. Should we _choose_ to use these classes, that is our decision; should we _choose_ to use ODBC or JDBC to accomplish the same thing, that, again, is our decision. These choices are based on any number of things, including time to get the job done. If there isn't as much time, go for the more generic solution. OTOH, if time is sufficient, write the server piece that knows how to talk to various platforms, and write the client to speak to the server, effectively isolated from all concerns about platform specifics. >>Obviously, the best combination would be a platform independant client >>written in an OO language that addresses a CORBA standard interface. Say, a >>Java client talking to a DSOM Java server object. > >BINGO! Fat Chance!! >>> This idea of platform-specific client code goes against the grain of OO >>> design, but I'm sure that they're out there... >> >>I would imagine that the largest amount of OO programs in existance are >>platform specific. But I do know that there is a lot of work being done both >>object based, and platform independant. > >If you're the designer, and you have the opportunity to write both sides >of the application, why would you write platform limited, um, I mean >platform specific code? > >>Probably all this is is a little semantic confusion. Often, though, people >>new to OO programming and object based systems get thrown off course by these >>semantic differences and so I think it's important to be clear. Eschew obfuscation! >Agree 1000% !!! > >Buck Calabro >Commsoft Cheers Vernon Hamberg Systems Software Programmer Old Republic National Title Insurance Company 400 Second Avenue South Minneapolis, MN 55401-2499 (612) 371-1111 x480 +--- | This is the Midrange System Mailing List! | To submit a new message, send your mail to "JAVA400-L@midrange.com". | To unsubscribe from this list send email to JAVA400-L-UNSUB@midrange.com. | Questions should be directed to the list owner/operator: email@example.com +---
As an Amazon Associate we earn from qualifying purchases.
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.