views:

34

answers:

2

I'm writing an application that creates catalogs of files. Currently the catalog information is stored in an XML file, but I'm trying to abstract the interface to a catalog to allow for other future storage mechanisms such as a single ZIP file, SQL server, or HTTP server. So rather than returning a file path the abstract Catalog class returns files as byte Streams. Thus allowing the source of a file to be a disk, but also for files coming from a database or a web server. See my previous related question.

However, the root Stream class includes Streams with different capabilities. Some streams can only be read, others can only be written to. Still some streams support seeking, while other streams do not.

Is there anyway to restrict the capabilities of the stream returns by a property or method? For example my Catalog class looks something like this.

public abstract class Catalog
{
    ...
    public abstract Stream File
    {
        get;
    }
    ...
}

Is there someway to ensure that File will always return a readable stream that supports seeking?

A: 

howabout abstracting the underlying persistance mechanism. What do your callers need? If they all need the same behaviour from your 'File', can you not create an interface which all your potential stores to implement, rather than have them all return 'Stream' classes?

Noel Kennedy
+1  A: 

Well, you can check the CanRead, CanWrite and CanSeek properties of the stream.

I'm not sure I understand your question correctly, though... What are you trying to do exactly ?

Some streams will never be seekable (for instance NetworkStream, GZipStream...), so if you're working on those types of stream, there is no way to force them to seek.

If you just want to restrict the functionality of a stream (for instance, prevent writing to a stream that is normally writable), you can create a wrapper that delegates its implementation to the underlying stream, but throws an exception for "disabled" methods.

Thomas Levesque
Sorry if I wasn't clear. I was wondering if there was a way, other then just documentation, that I could do to ensure that implementations of Catalog always return a stream from the File property with a certain set of capabilities. Say Streams that are readable and seekable.
Eric Anastas