The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Interface to objects/code representing resources

Alright, so the title is confusing, I agree.  What I mean is, suppose I wanted to write a general interface to a resource that had to be initialized (think: database, file, some kind of hardware, a webpage, etc.).  I want to write the interface so that I can write classes (we're talking OOP here) that implement that interface, but provide different resources.  For example, suppose I wanted something like IEnumerator from C#:

public interface IEnumerator
{
object Current;
bool MoveNext();
void Reset();
} /*note this is from memory, so if I spec'd it wrong, sorry.*/

The problem here is that this construction assumes that the resource is available from the outset.  If you are connecting to a webpage, there are lots of things that could make that assumption not true (router is down, website is down, etc).  I need something that let's the caller know that the resource isn't ready because the caller has to do something else if it is not.  So far, I have come up with the truly simplistic:

public interface IInitialzedEnumerator
{
bool Initialized;
object Current;
bool MoveNext();
void Reset();
}

At least this way the caller can test to see if the resource is available without having to know what the resource is. 

Does anybody have any other ideas for a solution to this problem?  PLMK.
Josh Volz Send private email
Thursday, January 26, 2006
 
 
I'd probably implement something similar to what you have already.  You can use the IsReady or IsInitialized or whatever property as a precondition for the other methods and properties on your class that way and it makes a tighter design.

One alternative, though, might be to allow resources to only be created by a resource factory that knows what to do if things aren't the way they are supposed to be at creation time.
another idea Send private email
Thursday, January 26, 2006
 
 
What's with the "object"?? Interfaces only have methods...
Stan
Thursday, January 26, 2006
 
 
In C# interfaces have methods and properties.  The "object" there is the return type of a property.  In this case, basically anything can be returned.
Josh Volz Send private email
Friday, January 27, 2006
 
 
The syntax for a property in an interface is actually:

bool Initialized { get; }

But that's beside the point.

I think you're forgetting an option. If the object is unavailable, why not throw an exception? That's what exceptions are for. It's not like the object is at all usable if the resource it's wrapping is unavailable.
Chris Tavares Send private email
Friday, January 27, 2006
 
 
Yeah, I forgot the "get".  Silly me.  I guess that's why we have compilers! :)

I thought of possibly throwing an exception, but I wanted to be more explicit with the interface (some people call it a contract).  The contract is a little more muddled with an exception because each each object that implements the interface could potentially throw a different one, which makes it more annoying to deal with from the caller perspective if the caller is trying to only catch the correct exception, IMO. 

Furthermore, I wasn't sure that state was "exceptional".  I wouldn't want people to have to wrap their calls in try blocks everytime, particularly for a state that has this high of a chance of happening. 

All that being said, I think that is how files work in .NET, you get an IOException if there is a problem.  Are there structurual or usage advantages I am not seeing with an exception in this role?
Josh Volz Send private email
Friday, January 27, 2006
 
 
I would do both! have a test that can test for availability and if something goes wrong throw an exception. This way you can test for availability first and avoid the exception if you so choose.

If you look at the file system access stuff you can test for file availability like .Exists() before attempting to access it; even with this check other exceptions can be raised or even the file being deleted between the call to exists and call to open the file.

So you will of course have to wrap the call in a try/catch block as with most external access it can be available one nano second and not the next.

There is no silver bullet here; no right or wrong answer; go with what seems intuitive for a developer reading your code or using the code as an sdk. I think if you choose the exception route then be consistent with your approach, there is nothing more frustrating than two error handling models in a single library.
Dave Barker Send private email
Friday, January 27, 2006
 
 
You're going to need the exception, even if you do have the check function. Whenever you deal with external resources like the network or files, there's nothing to stop the state of that resource from changing after you call .IsReady( ). IsReady( ) only tells you that the resource is ready NOW; it doesn't protect you three lines later when you actually try to read.
Chris Tavares Send private email
Friday, January 27, 2006
 
 
I agree that because of the leaky abstraction that we are going to have to throw an exception even if the calling code using the IsInitialized method (or property).  I was trying to avoid making that exception be specific, as in it might not always be a IOException, sometimes it might be something else.  I was trying to prevent the caller from having to know what kind of exception might come back.  Yes, we can just catch them all from the caller code with a general exception, but it might be the case that that exception be of various different types (IOException, WebException, etc.).  I don't want the caller to have to know what resource is getting read by the enumeration, and hence I don't want to necessarily expose that information by explicitly (stated in the documentation) expecting the caller to catch a particular exception type. 

It might be an idea to invent my own exception type.  That way the exception that comes back is always the same type of exception. 

It is probably the case that I am beating a dead horse and procrastinating.  I have recently startted placing more and more importance on reusable, decoupled code.  Also, it is kind of fun to think that your algorithm could get information from various different sources, just by having different resource handlers implementing the interface.
Josh Volz Send private email
Friday, January 27, 2006
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz