Help with Extending a class  
Author Message
KDawg44





PostPosted: 2007-6-19 0:57:00 Top

java-programmer, Help with Extending a class Hi,

I am writing a distributed Battleship game using RMI. I need this
class to extend both javax.swing.JFrame AND UnicastRemoteObject. Is
there anyway around this?


public class MainGUI extends javax.swing.JFrame implements
BattleShipClientIntf {


Thanks.

 
Lew





PostPosted: 2007-6-19 3:15:00 Top

java-programmer >> Help with Extending a class KDawg44 wrote:
> Hi,
>
> I am writing a distributed Battleship game using RMI. I need this
> class to extend both javax.swing.JFrame AND UnicastRemoteObject. Is
> there anyway around this?

You might be better off having your class contain and control a JFrame rather
than extending it. Also, it should likely use a UnicastRemoteObject rather
than extend it. Isn't the Swing interface going to be strictly on the client
side? Why would you need to pass a JFrame over the wire?

See Joshua Bloch's chapter in /Effective Java/ for "Prefer Composition to
Inheritance".

--
Lew
 
KDawg44





PostPosted: 2007-6-19 3:25:00 Top

java-programmer >> Help with Extending a class On Jun 18, 2:15 pm, Lew <email***@***.com> wrote:
> KDawg44 wrote:
> > Hi,
>
> > I am writing a distributed Battleship game using RMI. I need this
> > class to extend both javax.swing.JFrame AND UnicastRemoteObject. Is
> > there anyway around this?
>
> You might be better off having your class contain and control a JFrame rather
> than extending it. Also, it should likely use a UnicastRemoteObject rather
> than extend it. Isn't the Swing interface going to be strictly on the client
> side? Why would you need to pass a JFrame over the wire?
>
> See Joshua Bloch's chapter in /Effective Java/ for "Prefer Composition to
> Inheritance".
>
> --
> Lew

Thanks for the advice. I separated the classes. I was making it
harder than it had to be.

Another question... I need to do two way communication on my
implementation. I need my client to call methods at the server
(works) and then I need my server to respond and call methods at the
client. What I don't understand is how to do the naming lookup at the
server side?

Thanks very much.

 
 
Lew





PostPosted: 2007-6-19 3:33:00 Top

java-programmer >> Help with Extending a class KDawg44 wrote:
> Another question... I need to do two way communication on my
> implementation. I need my client to call methods at the server
> (works) and then I need my server to respond and call methods at the
> client. What I don't understand is how to do the naming lookup at the
> server side?

Disclaimer: There are bound to be other folks with a different take on your
question than mine, possibly better. "YMMV", etc.

Whenever possible I recommend not having both sides be initiators of a call.
You have to do so much dancing to handle it that it's not usually worth it.
It's almost always much better to have a client be the client and a server be
the server, never the roles to switch. Only the client should initiate
service calls; the server should only respond.

What is the client doing while waiting for the server to call back?

If you want a simulation of asynchronous RMI calls, spawn a client thread to
call for the result and wait for the reply. Have it asynchronously signal
your primary thread when the result is ready.

Why do you feel the need for server calls to the client? Perhaps by stepping
to a wider outlook we can perceive a simpler solution to a desirable result
based on different premises.

--
Lew
 
 
KDawg44





PostPosted: 2007-6-19 3:43:00 Top

java-programmer >> Help with Extending a class On Jun 18, 2:32 pm, Lew <email***@***.com> wrote:
> KDawg44 wrote:
> > Another question... I need to do two way communication on my
> > implementation. I need my client to call methods at the server
> > (works) and then I need my server to respond and call methods at the
> > client. What I don't understand is how to do the naming lookup at the
> > server side?
>
> Disclaimer: There are bound to be other folks with a different take on your
> question than mine, possibly better. "YMMV", etc.
>
> Whenever possible I recommend not having both sides be initiators of a call.
> You have to do so much dancing to handle it that it's not usually worth it.
> It's almost always much better to have a client be the client and a server be
> the server, never the roles to switch. Only the client should initiate
> service calls; the server should only respond.
>
> What is the client doing while waiting for the server to call back?
>
> If you want a simulation of asynchronous RMI calls, spawn a client thread to
> call for the result and wait for the reply. Have it asynchronously signal
> your primary thread when the result is ready.
>
> Why do you feel the need for server calls to the client? Perhaps by stepping
> to a wider outlook we can perceive a simpler solution to a desirable result
> based on different premises.
>
> --
> Lew

In the Battleship game, the client shoots then the server returns
fire. I see your point. It would be a lot better if the server
generated a shot and then the client got it with a remote method call.

Thanks for helping me clear this up.

 
 
Lew





PostPosted: 2007-6-19 6:33:00 Top

java-programmer >> Help with Extending a class Lew wrote:
>> What is the client doing while waiting for the server to call back?
>>
>> If you want a simulation of asynchronous RMI calls, spawn a client thread to
>> call for the result and wait for the reply. Have it asynchronously signal
>> your primary thread when the result is ready.
>>
>> Why do you feel the need for server calls to the client? Perhaps by stepping
>> to a wider outlook we can perceive a simpler solution to a desirable result
>> based on different premises.

KDawg44 wrote:
> In the Battleship game, the client shoots then the server returns
> fire. I see your point. It would be a lot better if the server
> generated a shot and then the client got it with a remote method call.
>
> Thanks for helping me clear this up.


But back to my first question:
>> What is the client doing while waiting for the server to call back?

Doesn't the client have to wait for the server to fire before it can do anything?

If so, just have the server's shot be part of the response from the RMI call
that registers the client's shot.

--
Lew