recursive classes

A

Andy

Hi all,

I want to build two classes, say A and B, where A contains a number of
instances of B and vice versa.

My first stab was to create two maps, one for each class; give each
(empty) instance an id, then fill in the details on another run,
accessing each instance from the map by its id.

This seems a bit clumsy though and I wondered if anyone had come
across a similar problem.

Thanks,

Andy
 
J

John C. Bollinger

Andy said:
Hi all,

I want to build two classes, say A and B, where A contains a number of
instances of B and vice versa.

My first stab was to create two maps, one for each class; give each
(empty) instance an id, then fill in the details on another run,
accessing each instance from the map by its id.

This seems a bit clumsy though and I wondered if anyone had come
across a similar problem.

Java is okay with many kinds of cycles in class dependency graphs. You
are probably trying to solve a problem that doesn't exist. For
instance, the following compiles fine for me (Java 1.4.2):

==== Cyclic.java ====

public class Cyclic {
OtherCyclic[] others;
}

class OtherCyclic {
Cyclic[] cyclics;
}

==== end of source ====

Add suitable constructors and you can create each instance of each class
with whatever collection of objects you like. This will work if the
objects are arranged in a tree-like structure, but if you have cycles in
the reference graph then you cannot avoid a two-pass approach.

If you're looking for a better two-pass implementation then you'll have
to be a lot more specific about the nature of the classes involved and
their relationships one to the other. There is no single answer.

Finally, you may want to consider whether there is a better design. The
kind of dependencies you describe are sometimes a sign of a suboptimal
design. You might get suggestions for better if you can give us enough
information about what you're trying to do.


John Bollinger
(e-mail address removed)
 
R

Roedy Green

Java is okay with many kinds of cycles in class dependency graphs. You
are probably trying to solve a problem that doesn't exist.

The only catch is you must give them both to JavaC at once to compile.

You can't write one class, compile it, then write the other.
 
J

John C. Bollinger

Roedy said:
The only catch is you must give them both to JavaC at once to compile.

You can't write one class, compile it, then write the other.

Which only makes sense. Once you have class files for both, however,
you don't have to compile both sources together every time.


John Bollinger
(e-mail address removed)
 
R

Roedy Green

Which only makes sense. Once you have class files for both, however,
you don't have to compile both sources together every time.

IIRC, if you erase the class files, you must again present both Java
files at once to Javac. In theory Javac should be able to go find the
other Java file for itself, but does it?

This would hint that traditional builds should screw up with cross
referencing classes.

you are best to just feed the universe to JavaC at once using the
class interface and let it sort it out. Then it loads the JVM only
once. We speeded up builds by orders of magnitude with this approach
back in the 90s. This was pre-Ant days. Perhaps it is much smarter
than the makes of yesteryear.

If that fails, delete all class files and give it another shot.
 
A

Andy

Hi John,

Before writing this post I must declare that this problem is part of a
dissertation I'm writing for an MSc...so don't be too forthcoming with
solutions or else I'll feel as if I haven't earned it ;-)

However, the problem is quite an interesting one and you might like to
hear about it so...

The two classes represent entities that have preferences over one
another. So for example

class Man {

List preferences; //is an ordered list of Woman objects
}

class Woman {

List preferences; //is an ordered list of Man objects
}

The interesting part is that you have to pair up the Man and Woman
objects such that no member of any pair could find a better partner
than the one they are allocated with (given the preferences of all the
"opposing" objects).

A bonus puzzle (for added kudos) is that one of the objects should be
allowed to express indifference in their preferences; so for example,
woman#1 likes man#1 better than both man#2 and man#3, but is
indifferent between man#2 and man#3.

The actual algorithm for the problem has already been published; all I
have to do is implement it in java.

Have fun with it,

Andy

ps I'm serious about the declaration at the top. I'm not looking for
easy answers here, I just thought you might be interested :)
 
R

Roedy Green

The actual algorithm for the problem has already been published; all I
have to do is implement it in java.

what is the measure of an optimal solution: max matches? minimally
least unhappy person, minimally least unhappy man, max number of
totally happy people? Highest average matches per person?

It is like political debate in miniature.
 
A

Andy

Roedy Green said:
what is the measure of an optimal solution: max matches? minimally
least unhappy person, minimally least unhappy man, max number of
totally happy people? Highest average matches per person?

For this project, it is max matches

It is like political debate in miniature.

I wonder if computers would be better at debating than politicians.

-Andy
 
J

John C. Bollinger

Andy said:
The two classes represent entities that have preferences over one
another. So for example

class Man {

List preferences; //is an ordered list of Woman objects
}

class Woman {

List preferences; //is an ordered list of Man objects
}

I don't see anything there that requires you to use separate classes for
the two kinds of people you're dealing with. That's irrelevant,
however. If every Man must prioritize his preferences for every Woman,
and every Woman for every Man, then there is no alternative to
completing the preference lists after completing the Man / Woman
construction. I.e. no Woman can explicitly represent her preference
level for a Man that doesn't exist. It is conceivable that the
prioritization could be interleaved with the object construction, but I
don't see any advantage to that, and it doesn't change my assertion. I
observe that the above holds true even if the registry of preferences is
maintained outside the scope of the Man and Woman objects, although that
might still be a preferable design.


John Bollinger
(e-mail address removed)
 
A

Andrew Chambers

John C. Bollinger said:
I don't see anything there that requires you to use separate classes for
the two kinds of people you're dealing with.

Well there are 2 major differences that I'd omitted in the snippets
above

1. men are allowed to express indifference in their preferences.
Consequently, the preference lists have a slightly different
data-structure.

2. these men are somewhat unfaithful and as such are permitted more
than one wife (although they are kind enough to commit to a quota of
wives before the program executes).

Another reason for two separate classes is that the matching algorithm
requires the objects to behave in slightly different ways (I could
discuss this more if you're interested - though it should probably be
started in a new thread with a more appropriate subject line. Here's
a taster http://www.dcs.gla.ac.uk/research/algorithms/stable/).
If every Man must prioritize his preferences for every Woman,
and every Woman for every Man, then there is no alternative to
completing the preference lists after completing the Man / Woman
construction. I.e. no Woman can explicitly represent her preference
level for a Man that doesn't exist. It is conceivable that the
prioritization could be interleaved with the object construction, but I
don't see any advantage to that, and it doesn't change my assertion. I
observe that the above holds true even if the registry of preferences is
maintained outside the scope of the Man and Woman objects, although that
might still be a preferable design.

Cool - I'll leave it the way it is then :)

Thanks for your comments. It definately helps me to discuss these
issues with experienced programmers.

Andrew Chambers
(e-mail address removed)
(hehe don't need to worry bout spam no more since I came across a
monster email account)
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,904
Latest member
HealthyVisionsCBDPrice

Latest Threads

Top