aspose file tools*
The moose likes Beginning Java and the fly likes OOP quandry - visibility of dynamically instantiated objects Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Beginning Java
Bookmark "OOP quandry - visibility of dynamically instantiated objects" Watch "OOP quandry - visibility of dynamically instantiated objects" New topic
Author

OOP quandry - visibility of dynamically instantiated objects

Jonathan Glass
Greenhorn

Joined: Jan 23, 2007
Posts: 11
Hi - I wonder if anyone can provide some guidance on the following.

After instantiating an object I can't figure out how to make the object visible to a separate process. For example:


Now if there's another process that wants to see how much duck1 weighs, it can't even though class Duck is public and duck.getWeight is public. Only the instantiating method (DuckWorld.main in this case) has access to duck1 and its members. One could use a static object instead, e.g.:


Now any process out there can view and/or manipulate DuckWorld.staticDuck1 and can even import static DuckWorld.* to avoid using the DuckWorld qualifier. This is not the solution I'm looking for, though, because we had to know to how many ducks would be created when we made the class; what if the number of ducks created is determined dynamically by the user at runtime?
So the question is, what can you do if you want process B to view and/or manipulate objects created dynamically by process A?
Ernest Friedman-Hill
author and iconoclast
Marshal

Joined: Jul 08, 2003
Posts: 24184
    
  34

Hi,

When you say "process" do you actually mean separate operating system processes -- i.e., separately launched programs? Note that the values of static variables, like all Java variables, are confined to the individual Java virtual machine in which they are created. In other words, if I write a program that continuously prints the value of a static int in some class, and I have another program that continuously increments that same static variable in that same class, and I run them at two different command prompts on my computer, then the printing program will just print "0... 0... 0". Each program has its own copy of static variables (actually, each program might have several copies, but we'll save that wrinkle for another time.)

If two programs need to share data or otherwise communicate, then they must do so explicitly. They will generally communicate via some form of networking: raw sockets, HTTP, RMI, CORBA... there are many choices, but none of them are invisible. You can find background information about any of these elsewhere on the Ranch, in Sun's documentation, or via Google -- if you have any specific questions we could answer them here.


[Jess in Action][AskingGoodQuestions]
Jonathan Glass
Greenhorn

Joined: Jan 23, 2007
Posts: 11
Ernest - Thanks so much for what I now see was a very prompt reply! I wasn't on Java Ranch until today since the day of my post, and I thought I would get an email notifications of replies (I must have forgotten to check the box). Going forward I'll log a bit after posting.

By "process" I mean another thread of the program or any method running that can't refer to a particular class instance (like duck1 in my example). I recently moved from procedural to OOP programming, and I keep feeling I need to make my class members static so that I can get at them directly from anywhere. Indeed the application I am developing uses threads and various kinds of composition / delegation, and I often find myself writing methods which need to access values which have been set in variables in other classes. I feel like I'm not harnessing the power of OOP by creating so many static members, but the scope of instance variables seems limiting. Rereading my post a month later, I sense it may not have a specific answer, and I think I need to ponder this more before I can even better-form the question. If anyone happens to have a quick idea of what might be helpful for me to do or ask myself, that would be appreciated, but I may need to work through my issue more in order to solve or better phrase my problem.

Thanks,
Jonathan
Ernest Friedman-Hill
author and iconoclast
Marshal

Joined: Jul 08, 2003
Posts: 24184
    
  34

Don't use static variables for this reason -- they're just the global variables you're used to from procedural programming, and overusing them is just as bad.

Instead, pass things from method to method. In your example, since main() has the Duck, it's up to main() to hand out the Duck to other code: "tell, don't ask." To stick with the Duck example: let's say your duck is feeling under the weather. Luckily, you have a Veterinarian class:



Let's say that, having created a pair of Ducks, you'd like to set up a farm farm for them to live on, and send them on their way in their own thread since that's something you specifically asked about. Here I'll use constructor parameters:




Note that every thread has to start somewhere; you don't have a program with random threads floating in space. There's always a place where threads get started, and that's where they can get set up with data like this.
Jonathan Glass
Greenhorn

Joined: Jan 23, 2007
Posts: 11
Thanks Ernest for taking the time to respond so clearly and promptly (not to mention humoursly). I see I have to get in the habit of passing needed info along to methods and instances instead of sticking info up in the sky (i.e. in global variables) for everyone to see.
Jonathan
Bob Ruth
Ranch Hand

Joined: Jun 04, 2007
Posts: 320
Just for the sake of discussion.....

You mentioned another thread needing access to the ducks....

That brings about the possibility of creating a collection (ArrayList, LinkedList) and managing it with a coordinating object and synchronizing each threads access to it. Yes, it is opening a can of worms, but if you want some other thread to be able to just "take a peek" now and then at how many ducks there are and keeping an eye on them.... this would be the direction that your research should take you. Multi-threaded application sharing synchronized access to a container..... that's the ticket!


------------------------
Bob
SCJP - 86% - June 11, 2009
 
jQuery in Action, 2nd edition
 
subject: OOP quandry - visibility of dynamically instantiated objects