Home > Archive > Java Help > January 2005 > objectA gives objectB to objectC
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
objectA gives objectB to objectC
|
|
| thufir 2005-01-27, 8:58 am |
| given that the class Sword is in an entirely different package,
Weapons.jar, for which the source code is unavailable, can one monster
give an instance of Sword to a second monster instance? something
like:
{ //put this in TestDriveMOnsters
Sword excalibur = new Sword();
Monster barney = new Monster();
Monster fred = new Monster();
//barney gets excalibur, but how?
//barney gives excalibur to fred, but how?
}//end example
How does barney even get excalibur?
//////////////code//////////////
package atreides.monsters;
public class Monster{
boolean isDaemon = false;
java.util.Timer melee = new java.util.Timer(isDaemon);
public Monster(){}//Monster
public void setScheduleMelee(long period){
System.out.println("..setScheduleMelee");
period = 4000;
java.util.TimerTask dummyTask = new MonsterTask();
java.util.Date nowDate = new java.util.Date();
melee. scheduleAtFixedRate(dummyTask,period,per
iod);
}//setScheduleMelee
public static void main (String args[]) {
System.out.println("main..");
}//main
}//Monster
////////////////////////////code///////////////////
package atreides.monsters;
import java.util.*;
public class TestDriveMonsters{
private static List<Monster> list = new ArrayList<Monster>();
public TestDriveMonsters(){
System.out.println("TestDriveMonsters..");
}//TestDriveMonsters
public static void makeMonsters(){
System.out.println("..makeMonsters");
for (int i=0; i<5; i++){
list.add(new Monster());
}//for
}//makeMonsters
public static void setTimer(){
System.out.println("..addTimer");
for (Monster monster:list){
}//for
}//setTimer
public static void main (String args[]) {
System.out.println("..main");
makeMonsters();
setTimer();
}//main
}//TestDriveMonsters
//////////////////////code///////////////
package atreides.monsters;
public class MonsterTask
extends java.util.TimerTask{
public MonsterTask(){}//MonsterTask
public boolean cancel(){
return false;
}//cancel
public void run(){
System.out.println("..run");
}//run
public long scheduledExecutionTime(){
return 0;
}//scheduledExecutionTime
public static void main (String args[]) {
System.out.println("main..");
}//main
}//MonsterTask
thanks,
Thufir Hawat
| |
|
| > given that the class Sword is in an entirely different package,
> Weapons.jar, for which the source code is unavailable, can one monster
> give an instance of Sword to a second monster instance?
Sure, why not. Just let him put enough stamps on the package.
> How does barney even get excalibur?
By Fedex.
> thanks,
>
> Thufir Hawat
>
You're welcome. If you have any more homeworks, please do not hesitate to
post here, specially when you have shown so much interest and effort in
solving them by yourself as you did in this one.
Best of luck.
hilz.
| |
| Bjorn Abelli 2005-01-27, 8:58 am |
|
"thufir" wrote...
> given that the class Sword is in an entirely different
> package, Weapons.jar, for which the source code is
> unavailable,
Don't confuse "packages" with "jars". These are two different concepts.
Packages are a "logical" classification of classes, while jars are a
"physical" division.
A jar can contain classes from several packages, and there can exist classes
from the same package in many jars.
You include the jars in your classpath when compiling and executing, so the
JVM can find the classes inside them.
You "import" the packages in you source code, just as you do with
"java.util.*", etc...
Say that the full name of Sword really is atreides.weapons.Sword, then you
have to
import atreides.weapons.Sword;
or
import atreides.weapons.*;
where you intend to reference to Swords.
> can one monster give an instance of Sword to a
> second monster instance?
Absolutely.
You could add these lines somewhere in Monster
public class Monster {
private Sword = null;
public void achieveSword (Sword s) {
sword = s;
}
public Sword returnSword () {
Sword s = sword;
sword = null;
return s;
}
public void giveAwaySword(Monster m) {
m.achieveSword( this.returnSword() );
}
}
> something like:
>
> { //put this in TestDriveMOnsters
> Sword excalibur = new Sword();
> Monster barney = new Monster();
> Monster fred = new Monster();
> //barney gets excalibur, but how?
barney.achieveSword(excalibur);
> //barney gives excalibur to fred, but how?
barney.giveAwaySword(fred);
> }//end example
Suggestion:
Read up on OO Analysis and Design, the parts that describes responsibilities
of objects and classes, sending messages, delegation, etc.
To visualize such events you can also look into how you can use sequence
diagrams in UML.
// Bjorn A
| |
| thufir 2005-01-27, 8:58 am |
| hilz wrote:
[..]
> You're welcome. If you have any more homeworks,
[..]
What led you to that conclusion?
--
Thufir Hawat
| |
| thufir 2005-01-27, 8:58 am |
| Bjorn Abelli wrote:
> "thufir" wrote...
>
> Don't confuse "packages" with "jars". These are two different
concepts.
You're right, I meant that the weapons would be in Weapons.jar
[..]
> You could add these lines somewhere in Monster
>
> public class Monster {
>
> private Sword = null;
>
> public void achieveSword (Sword s) {
> sword = s;
> }
>
> public Sword returnSword () {
> Sword s = sword;
> sword = null;
> return s;
> }
>
> public void giveAwaySword(Monster m) {
> m.achieveSword( this.returnSword() );
> }
> }
[..]
Sorry, I mis-stated my question. Can this be done from *outside* the
Monster class? For example, assume that Monster is final and is in
package atreides.monsters, for which the .class file(s) are in
Monster.jar, and the Monster source code can't be edited.
>From TestDriveMonsters I don't see how a atreides.weapons.Sword
instance could be given to a Monster instance (and then to a different
Monster instance).
I hope that clarifies what my question is, sorry my initial question
wasn't clear enough. I ask this because there might be 500 different
"things" a Monster might be "composed" of, none of which can really be
anticipated in advance.
Perhaps if Sword implemented interface Givable (or such) that'd
eliminate 500 different methods to pick up 500 different objects? I
think so...don't know why I didn't think of that before posting.
If an interface were to enable a Monster instance to "get" an object,
which is unknown in advance, that's what I'll do. However, is there
more than one way to skin this cat, parenthetically speaking?
thanks,
Thufir Hawat
| |
| Stefan Schulz 2005-01-27, 8:58 am |
| On Thu, 27 Jan 2005 02:32:34 -0800, thufir wrote:
> hilz wrote:
> [..]
> [..]
>
> What led you to that conclusion?
Well, you _do_ ask a lot of questions that normally (sorry) an novice with
little to no grasp on the language would ask. I suggest you do some
easier, smaller projects before you tackle what looks like a pretty
complicated game. Get a "feel" for the language, get fluent in it. (Sorry
to say so, but you are far from it right now).
--
In pioneer days they used oxen for heavy pulling, and when one ox
couldn't budge a log, they didn't try to grow a larger ox. We shouldn't
be trying for bigger computers, but for more systems of computers.
--- Rear Admiral Grace Murray Hopper
| |
| Stefan Schulz 2005-01-27, 8:58 am |
| On Thu, 27 Jan 2005 02:51:46 -0800, thufir wrote:
> I hope that clarifies what my question is, sorry my initial question
> wasn't clear enough. I ask this because there might be 500 different
> "things" a Monster might be "composed" of, none of which can really be
> anticipated in advance.
In that case, you should introduce some subclasses of Monster that are
generic "kinds" of monster which share common characteristics. For
example, you could create a "Humanoid" class, which extends monster, and
includes such things as being able to get, wield, and otherwise use items.
> Perhaps if Sword implemented interface Givable (or such) that'd
> eliminate 500 different methods to pick up 500 different objects? I
> think so...don't know why I didn't think of that before posting.
Yes. You could also implement a "take(Item)" method, that enables the
monster to take any kind of Item (not just Swords) if it wants, or
something similar. This is what OO is really about!
> If an interface were to enable a Monster instance to "get" an object,
> which is unknown in advance, that's what I'll do. However, is there
> more than one way to skin this cat, parenthetically speaking?
> thanks,
Of course, there is. For example, either introduce a Takeable interface,
that objects that can be taken implement, or introduce an (abstract) Item
class, which includes a isTakeable(Monster) method... or a dozen other
variations on these themes.
--
In pioneer days they used oxen for heavy pulling, and when one ox
couldn't budge a log, they didn't try to grow a larger ox. We shouldn't
be trying for bigger computers, but for more systems of computers.
--- Rear Admiral Grace Murray Hopper
| |
| Bjorn Abelli 2005-01-27, 8:58 am |
|
"thufir" wrote...
> [..]
>
> Sorry, I mis-stated my question. Can this be done from *outside* the
> Monster class? For example, assume that Monster is final and is in
> package atreides.monsters, for which the .class file(s) are in
> Monster.jar, and the Monster source code can't be edited.
Do you mean that *both* Monster and Sword are classes that you can't change
the source codes for?
In that case you really mislead me, as you provided a sample code of
Monster...
To help you further, you should at least provide the interfaces of Sword and
Monster, to see what could be done.
> instance could be given to a Monster instance (and then to a different
> Monster instance).
>
> I hope that clarifies what my question is, sorry my initial question
> wasn't clear enough. I ask this because there might be 500 different
> "things" a Monster might be "composed" of, none of which can really be
> anticipated in advance.
So Monster *alreday* has ways to receive things?
And to give them back?
> Perhaps if Sword implemented interface Givable (or such) that'd
> eliminate 500 different methods to pick up 500 different objects? I
> think so...don't know why I didn't think of that before posting.
>
> If an interface were to enable a Monster instance to "get" an object,
> which is unknown in advance, that's what I'll do. However, is there
> more than one way to skin this cat, parenthetically speaking?
> thanks,
I see three ways to skin this cat... ;-)
In order of (my) preference:
1. a Monster has methods to receive and return things.
2. a Sword (or Giveable) has methods to store an owner (such as a Monster)
3. you implement a third "relationship class", which tells which artefact is
owned by who.
In many design patterns 1 and 2 are used together, and 3 is very seldom
used.
Which one that is best suited is depending on what is already implemented,
as it seems your access to the source code seem a bit restricted... ;-)
// Bjorn A
| |
| thufir 2005-01-27, 8:58 am |
| Heh, the access to the source was a (poor) device to ask the question.
Here's what I now have, what do you think of using a List of
MonsterItems (an interface)?
package atreides.monsters;
public class Monster{
boolean isDaemon = false;
java.util.Timer melee = new java.util.Timer(isDaemon);
private static java.util.List<MonsterItem> list =
new java.util.ArrayList<MonsterItem>();
public Monster(){}//Monster
public void setScheduleMelee(long period){
System.out.println("..setScheduleMelee");
period = 4000;
java.util.TimerTask dummyTask = new MonsterTask();
java.util.Date nowDate = new java.util.Date();
melee. scheduleAtFixedRate(dummyTask,period,per
iod);
}//setScheduleMelee
public static void main (String args[]) {
System.out.println("main..");
}//main
}//Monster
package atreides.monsters;
public interface MonsterItem{
public void give();
}//MonsterItem
package atreides.monsters;
public class MonsterTask
extends java.util.TimerTask{
public MonsterTask(){}//MonsterTask
public boolean cancel(){
return false;
}//cancel
public void run(){
System.out.println("..run");
}//run
public long scheduledExecutionTime(){
return 0;
}//scheduledExecutionTime
public static void main (String args[]) {
System.out.println("main..");
}//main
}//MonsterTask
package atreides.monsters;
public class Sword implements MonsterItem{
Sword(){}
public void give(){
System.out.println("..give");
}//give
}//Sword
package atreides.monsters;
import java.util.*;
public class TestDriveMonsters{
private static List<Monster> list = new ArrayList<Monster>();
public TestDriveMonsters(){
System.out.println("TestDriveMonsters..");
}//TestDriveMonsters
public static void makeMonsters(){
System.out.println("..makeMonsters");
for (int i=0; i<5; i++){
list.add(new Monster());
}//for
}//makeMonsters
public static void setTimer(){
System.out.println("..addTimer");
for (Monster monster:list){
}//for
}//setTimer
public static void main (String args[]) {
System.out.println("..main");
makeMonsters();
setTimer();
}//main
}//TestDriveMonsters
| |
| thufir 2005-01-27, 4:03 pm |
|
Stefan Schulz wrote:
[..]
> Well, you _do_ ask a lot of questions that normally (sorry) an novice
with
> little to no grasp on the language would ask. I suggest you do some
> easier, smaller projects before you tackle what looks like a pretty
> complicated game. Get a "feel" for the language, get fluent in it.
(Sorry
> to say so, but you are far from it right now).
[..]
Most every day I make some progress. What better way to get fluent
than to tackle something beyond my reach? I doubt I'll finish the
game, it's more an exercise.
I've the monsters periodically executing MonsterTask.run(), next I'll
have monster 1 kill monster 2 :)
--
Thufir Hawat
| |
| Stefan Schulz 2005-01-27, 4:03 pm |
| On Thu, 27 Jan 2005 05:30:21 -0800, thufir wrote:
> Most every day I make some progress. What better way to get fluent
> than to tackle something beyond my reach? I doubt I'll finish the
> game, it's more an exercise.
Well, i just doubt the value of an exercise done by the newsgroup. ;)
Honestly, you won't always have a handy bunch of programmers ready to help
you out. Especially if your game progresses to be more complex then 3-4
classes, you'll need to be able to condense problems down to 1-2 classes.
Please don't take this as a personal attack, but you'll need some more
experience with tackling problems yourself. Get a book. Read it. Take a
good long walk in the JavaDocs, and jam yourself behind your computer for
a couple of hours if you have a problem. Post only if you can't find the
answer yourself. You'll learn things you never thought you might have to
know.
> I've the monsters periodically executing MonsterTask.run(), next I'll
> have monster 1 kill monster 2 :)
Hmm... how about a bet? If you manage to make that happen (and so that
monster 2 won't come back from the dead, and monster 1 gets notified when
it tries to kill the dead monster again), i'll revise my views. :)
--
In pioneer days they used oxen for heavy pulling, and when one ox
couldn't budge a log, they didn't try to grow a larger ox. We shouldn't
be trying for bigger computers, but for more systems of computers.
--- Rear Admiral Grace Murray Hopper
| |
|
|
"thufir" <thufir.hawat@mail.com> wrote in message
news:1106821954.039313.90160@f14g2000cwb.googlegroups.com...
> hilz wrote:
> [..]
> [..]
>
> What led you to that conclusion?
>
> --
> Thufir Hawat
>
Ok. I appologise.
Reading your other posts, I can now tell it is not really a homework.
But what really made me think that way was: "for which the source code is
unavailable".
But as Stefan said, you need to learn the basics before diving into the
code. Learning by trial and error is ok, but you need to get a basic level
of understanding of object oriented programming first.
Consider reading a book, or reading some literature on the web. You can find
most of what you need to get started at the java.sun.com website.
Good luck.
hilz
| |
| thufir 2005-01-29, 3:57 am |
|
hilz wrote:
[..]
> Reading your other posts, I can now tell it is not really a homework.
> But what really made me think that way was: "for which the source
code is
> unavailable".
Ah, I see why you thought it was homework. That was a poor way of
asking a simple question on my part.
> But as Stefan said, you need to learn the basics before diving into
the
> code. Learning by trial and error is ok, but you need to get a basic
level
> of understanding of object oriented programming first.
> Consider reading a book, or reading some literature on the web. You
can find
> most of what you need to get started at the java.sun.com website.
>
> Good luck.
> hilz
Thanks,
Thufir Hawat
| |
| thufir 2005-01-29, 8:56 am |
| Bjorn Abelli wrote:
[..]
> You could add these lines somewhere in Monster
>
> public class Monster {
>
> private Sword = null;
>
> public void achieveSword (Sword s) {
> sword = s;
> }
>
> public Sword returnSword () {
> Sword s = sword;
> sword = null;
> return s;
> }
>
> public void giveAwaySword(Monster m) {
> m.achieveSword( this.returnSword() );
> }
> }
>
[..]
> To visualize such events you can also look into how you can use
sequence
> diagrams in UML.
[..]
I need to step away from the code because I go in a chicken-or-egg
circle.
It must be possible to view a Monster's MonsterItems (an "inventory" of
sorts).
It must be possible to change the owner for a MonsterItem from one
Monster to
another Monster (ignoring "dropping a sword to the ground" for
simplicity).
some pseudo-UML:
<<MonsterItem>>
excalibur:Sword
<<MonsterItem>>
aToothpick:Sword
Barney:Monster
--------------
+getMonsterItem(Monster)
+giveMonsterItem(MonsterItem,Monster)
Fred:Monster
--------------
+getMonsterItem(Monster)
+giveMonsterItem(MonsterItem,Monster)
There's an aggregation of many MonsterItems in a Monster, but it's hard
to type
"open diamond from Monster to MonsterItem" with real diamond shapes ;)
It must also be possible to print "Barney attacks Fred with excalibur
for 3
points of damage," which is the litmus test. What's needed to add that
functionality to this model, please?
Thanks,
Thufir Hawat
who has complete access to the source ;)
| |
| thufir 2005-01-29, 8:56 am |
| Bjorn Abelli wrote:
[..]
> You could add these lines somewhere in Monster
>
> public class Monster {
>
> private Sword = null;
>
> public void achieveSword (Sword s) {
> sword = s;
> }
>
> public Sword returnSword () {
> Sword s = sword;
> sword = null;
> return s;
> }
>
> public void giveAwaySword(Monster m) {
> m.achieveSword( this.returnSword() );
> }
> }
>
[..]
> To visualize such events you can also look into how you can use
sequence
> diagrams in UML.
[..]
I need to step away from the code because I go in a chicken-or-egg
circle.
It must be possible to view a Monster's MonsterItems (an "inventory" of
sorts). It must be possible to change the owner for a MonsterItem from
one Monster to another Monster (ignoring "dropping a sword to the
ground" for simplicity).
some pseudo-UML:
<<MonsterItem>>
excalibur:Sword
---------------
+printDamage
<<MonsterItem>>
aToothpick:Sword
-----------------
+printDamage
Barney:Monster
--------------
+getMonsterItem(Monster)
+giveMonsterItem(MonsterItem,Monster)
+printDamageDone
+printDamageReceived
Fred:Monster
--------------
+getMonsterItem(Monster)
+giveMonsterItem(MonsterItem,Monster)
+printDamageDone
+printDamageReceived
There's an aggregation of many MonsterItems in a Monster, but it's hard
to type "open diamond from Monster to MonsterItem" with real diamond
shapes ;)
fred.PrintDamageDone should print "Fred uses excalibur"
excalibur.printDamage should print "excalibur delivers 4 points of
damage"
barney.printDamageRecived should print "barney takes 4 points of
damage"
However, this model seems deficient in that I don't see how to send
messages between the three different objects to effect those print
statements.
Thanks,
Thufir Hawat
|
|
|
|
|