By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
432,463 Members | 774 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 432,463 IT Pros & Developers. It's quick & easy.

are directories files?

P: n/a
Tum
Hi folks,

I've been trying to make a decision and it's driving me crazy.

Is a directory a file or is a directory NOT a file but a node?

Should I have

A)

public interface IFile
{
IFileName FileName;
IFileContent GetContent();
}

public interface IDirectory
extends IFile
{
}
or

B)

public interface INode
{
INodeName NodeName;
}

public interface IFile
extends INode
{
IFileContent GetContent();
}

public interface IDirectory
extends INode
{
}
Method A is nice cause IFile becomes the base "Node" type and you can use
names like "IFileName" which sounds nice compared to "INodeName" and fits
with the "FileSystem" moniker. A has the disadvantage that IDirectory has a
GetContent() method which isn't bad but can be considered a bit weird. It
probably wouldn't be too hard to make users think of everything as a file.

Method B is nice cause IDirectory doesn't have GetContent() -- that honour
belongs only to IFile. B is at a disadvantage when it comes to naming:
everything becomes a "Node". INodeName sounds rude compared to IFileName
and it's a bit weird to have everything based on something called a "Node"
when the system is called a "File System" but this method feels more "pure"
in the OO sense cause you're specialising features completely.

Do you reckon I can get away with Method A? It doesn't seem as pure unless
you spend a long time convincing yourself that (for all intents and
purposes) a file *is* a node (it's just got a different name) and a
directory *is* a file.

A penny for anyone's thoughts...
^Tum

Jul 17 '05 #1
Share this Question
Share on Google+
5 Replies


P: n/a
"Tum" <sp**@spam.com> wrote in message
news:%8********************@news02.tsnz.net...
Hi folks,

I've been trying to make a decision and it's driving me crazy.

Is a directory a file or is a directory NOT a file but a node?

Should I have

A)

public interface IFile
{
IFileName FileName;
IFileContent GetContent();
}

public interface IDirectory
extends IFile
{
}
or

B)

public interface INode
{
INodeName NodeName;
}

public interface IFile
extends INode
{
IFileContent GetContent();
}

public interface IDirectory
extends INode
{
}
Method A is nice cause IFile becomes the base "Node" type and you can use
names like "IFileName" which sounds nice compared to "INodeName" and fits
with the "FileSystem" moniker. A has the disadvantage that IDirectory has a GetContent() method which isn't bad but can be considered a bit weird. It
probably wouldn't be too hard to make users think of everything as a file.

Method B is nice cause IDirectory doesn't have GetContent() -- that honour
belongs only to IFile. B is at a disadvantage when it comes to naming:
everything becomes a "Node". INodeName sounds rude compared to IFileName
and it's a bit weird to have everything based on something called a "Node"
when the system is called a "File System" but this method feels more "pure" in the OO sense cause you're specialising features completely.

Do you reckon I can get away with Method A? It doesn't seem as pure unless you spend a long time convincing yourself that (for all intents and
purposes) a file *is* a node (it's just got a different name) and a
directory *is* a file.

A penny for anyone's thoughts...
^Tum

Since java.io.File covers both files and directories, it's not exactly a new
way of thinking.
Jul 17 '05 #2

P: n/a
nos

"Ryan Stewart" <zz********@gSPAMo.com> wrote in message
news:p8********************@texas.net...
"Tum" <sp**@spam.com> wrote in message
news:%8********************@news02.tsnz.net...
Hi folks,

I've been trying to make a decision and it's driving me crazy.

Is a directory a file or is a directory NOT a file but a node?

Should I have

A)

public interface IFile
{
IFileName FileName;
IFileContent GetContent();
}

public interface IDirectory
extends IFile
{
}
or

B)

public interface INode
{
INodeName NodeName;
}

public interface IFile
extends INode
{
IFileContent GetContent();
}

public interface IDirectory
extends INode
{
}
Method A is nice cause IFile becomes the base "Node" type and you can use names like "IFileName" which sounds nice compared to "INodeName" and fits with the "FileSystem" moniker. A has the disadvantage that IDirectory has
a
GetContent() method which isn't bad but can be considered a bit weird.
It probably wouldn't be too hard to make users think of everything as a file.
Method B is nice cause IDirectory doesn't have GetContent() -- that honour belongs only to IFile. B is at a disadvantage when it comes to naming:
everything becomes a "Node". INodeName sounds rude compared to IFileName and it's a bit weird to have everything based on something called a "Node" when the system is called a "File System" but this method feels more

"pure"
in the OO sense cause you're specialising features completely.

Do you reckon I can get away with Method A? It doesn't seem as pure

unless
you spend a long time convincing yourself that (for all intents and
purposes) a file *is* a node (it's just got a different name) and a
directory *is* a file.

A penny for anyone's thoughts...
^Tum

Since java.io.File covers both files and directories, it's not exactly a

new way of thinking.

This works

File f = new File(".");

Jul 17 '05 #3

P: n/a
> > > Do you reckon I can get away with Method A? It doesn't seem as pure
unless
you spend a long time convincing yourself that (for all intents and
purposes) a file *is* a node (it's just got a different name) and a
directory *is* a file.

A penny for anyone's thoughts...

Since java.io.File covers both files and directories, it's not exactly a

new
way of thinking.

This works

File f = new File(".");


Wow, profound and epigrammatic replies, but of course it depends a lot
on how you are going to implement the interfaces.

E.g., are you going to have many functions that are common to both
files and directories (e.g. delete, move, attributes etc.)? And is
there much code that needs to be used by both classes? Code
economy/reuse is my major consideration when making these decisions;
it would be bad to rewrite routines twice that would operate on both
files and directories, e.g. recursive copying etc.

Since files have properties that directories do not (as you describe
with getContents), and Dirs have some that files do not, a common Node
interface sounds more attractive to me. Directories might also have
extras that files do not, e.g. the ability to add leaf 'nodes' to
them, and the ability to retrieve a list of their children - methods
which files do not.

Any more pennies?
Jul 17 '05 #4

P: n/a
nos

"S Manohar" <sg*******@hotmail.com> wrote in message news:2e**************************@posting.google.c om...
> Do you reckon I can get away with Method A? It doesn't seem as pure

unless
> you spend a long time convincing yourself that (for all intents and
> purposes) a file *is* a node (it's just got a different name) and a
> directory *is* a file.
>
> A penny for anyone's thoughts...
>
Since java.io.File covers both files and directories, it's not exactly a

new
way of thinking.

This works

File f = new File(".");


Wow, profound and epigrammatic replies, but of course it depends a lot
on how you are going to implement the interfaces.

E.g., are you going to have many functions that are common to both
files and directories (e.g. delete, move, attributes etc.)? And is
there much code that needs to be used by both classes? Code
economy/reuse is my major consideration when making these decisions;
it would be bad to rewrite routines twice that would operate on both
files and directories, e.g. recursive copying etc.

Since files have properties that directories do not (as you describe
with getContents), and Dirs have some that files do not, a common Node
interface sounds more attractive to me. Directories might also have
extras that files do not, e.g. the ability to add leaf 'nodes' to
them, and the ability to retrieve a list of their children - methods
which files do not.

Any more pennies?


rewrite routines twice???
Jul 17 '05 #5

P: n/a
sg*******@hotmail.com (S Manohar) wrote in message news:<2e**************************@posting.google. com>...
[snipped...]
Wow, profound and epigrammatic replies, but of course it depends a lot
on how you are going to implement the interfaces.

E.g., are you going to have many functions that are common to both
files and directories (e.g. delete, move, attributes etc.)? And is
there much code that needs to be used by both classes? Code
economy/reuse is my major consideration when making these decisions;
it would be bad to rewrite routines twice that would operate on both
files and directories, e.g. recursive copying etc.

Since files have properties that directories do not (as you describe
with getContents), and Dirs have some that files do not, a common Node
interface sounds more attractive to me. Directories might also have
extras that files do not, e.g. the ability to add leaf 'nodes' to
them, and the ability to retrieve a list of their children - methods
which files do not.

Any more pennies?


It would appear that the only difference between files and directories
is their content type. A file has binary content, and the content
length is the number of bytes. A directory has list content, and the
content length is the number of entries in the list. Aside from this
there is practically no difference. Both have names, attributes and
permissions. Both can be 'soft' and 'hard' linked. Both can be
created, copied, moved and deleted.

So, you *can* think of them as one type of object with two content
type variations. Whether or not your *do* think of them in this way
is entirely dependent upon what you are doing!
-FISH- ><>
Jul 17 '05 #6

This discussion thread is closed

Replies have been disabled for this discussion.