mimic directory structure , array of objects

[michael]

thanks to one private email , the solution was simpler than I
imagined.

since each node has a unique ID , therefore flattening the structure
will give the best possible solution. another word , all nodes are
treated as files and
a simple array describes the data structure.

dataStructure f1[] = new dataStructure[100] , where dataStructure
class defines all required properties.

thanks
Michael

 

[Paul Lutus]

thanks to one private email , the solution was simpler than I
imagined.

If the problem is actually one "that mimics directory structure", as stated
above, it is not a solution at all.

since each node has a unique ID , therefore flattening the structure
will give the best possible solution.

To what problem? The one you never managed to state?

another word , all nodes are
treated as files and
a simple array describes the data structure.

This allows files with the same name to be inserted into the same
collection. Depending on the type of collection and the criteria for
sorting and retrival, this simply won't work.

dataStructure f1[] = new dataStructure[100] , where dataStructure
class defines all required properties.

This specific code example won't work, and you really need to state a
problem and your code.

In summmary, it is too bad you were unwilling to work on the original
problem or state it clearly. When you ask for help with a problem, try to
state the problem, not your idea of how it should be solved. People might
think your imagined solution *is* the problem to be solved.

Also, in this arrangement, if the filenames without the paths are used in a
hash, problems will arise for a reason you haven't thought about yet. In
the originally stated problem, this was solved by using a tree in which
same-name nodes were separated just as they are in the filesystem.

What you have done is backpedal instead of learning what you need to solve
the original problem.

 

[Grant Wagner]

class groups {
int size;
String Name;
String networkname;
String Capacity;
String [] files;

class files {
int size;
String Name;
String Capacity;
}

then an array of groups will define an structure similiar to a two
level diretory file system.

Is there any reason you hold an array of String names of "files" in your
groups" ? To me it would seem more natural for each Group to hold an array f
Files. Actually a java.util.List of some kind, probably a java.util.ArrayList,
would be better still. If you don't do that then you'll have difficulty
mapping from the String filenames to the actual files -- the natural approach
of using a java.util.HashMap won't work without a lot of added complication
because the Files' names are not necessarily unique (presumably the same name
can be used for two Files in different Groups).

Why not a "DirectoryEntry" class, subclassed into "Directory" and "File". Then you
could have

class Directory {
// ...
DirectoryEntry [] directoryEntries;
// ...
}

Directory rootDir = new Directory("path/to/directory");
// The Directory constructor would recursively walk
// the directory tree starting at the specified path

then

rootDir.directoryEntries[0].directoryEntries[1].directoryEntries[2].setName("thefilename.txt");

would set the name of the DirectoryEntry in the 3rd subdirectory of the second
subdirectory of the first directory in the rootDir (assuming each directoryEntries
Array actually has enough entries to avoid throwing an
ArrayIndexOutOfBoundsException somewhere along the way.

I wouldn't do it this way, but it seems to approximate what the OP thinks to be the
optimal solution to his problem.

Of course, as someone mentioned earlier, the closer your DirectoryEntry objects get
to mimicing the actual file system, the more and more it starts to look like
java.io.File.