thnx ssamuel and peter
The reason I asked for opions is that I'm, as my name states, a C# beginner.
Though I'm learning the language very quickly, I seem to have difficulties
with drawing a line between a class and a program. Which tasks should be
handled by the class and which ones should be handled by the program. Should
login attempts be handled by the class or handled by the program? etc.
I thought by using an event, the class could take control over the situation
(just give me a name and password and I handle it) intead of shoving the
problem to the program (access denied, solve it yourself), as I have
experienced using VB6 trying to open a secured database.
I've read a lot of books and I've learned to create execeptions, events &
delegates and so, but I never read a book explaining to me in which
situations I should use exceptions or events (I'm refering to dutch books).
Though solutions are good but I'm more interested in opinions because it's
the best way to learn.
thnx again
DD
"ssamuel" <
[email protected]> schreef in bericht
Peter is correct, as is his opinion.
The first option makes sense: you try to open something that you know
may or may not open, and the result indicates the status of the
operation. Since you may or may not be able to open the database,
TryOpen() may be more morally correct, but since the Try- prefix on
method names already means something subtly different, and Open()
already means what you're trying to do, Open(), as you had it, is
probably the best name too.
The second option involves an exception. As Peter stated, nothing
exceptional has happened. Exceptions are to be reserved for things like
users unplugging USB devices while we're accessing them, or disks not
having enough space to write log or temporary files. Throwing an
exception carries overhead; while overhead isn't something to be
eliminated, this case doesn't even follow the exception metaphor, so
it's purely wasted overhead.
Stating that the third is "too complicated" may be an understatement.
There are times and places when you want very, very heavyweight objects
that do things like fire events and wait for results. The only two I
can think of off the top of my head are either where the user is very
close to the object model or where the system has some ability to cope
with things like missing information and broken connections.
The first case is for things like APIs and user-programmable systems.
In these cases, you sometimes want "wrapper objects" around your core
objects. The wrappers make the API more like a UI, which is appropriate
in those circumstances. I'd have a hard time believing that this is the
best model for any API, however.
The second case is for an "intelligent" system. I've designed systems
that have things like defaults and base cases. If you tell them
something, they try different permutations until either something
works, or they run out of options. There are many ways to do this, but
one is to fire an event and wait for more information. For instance, if
you have a default username and password, you can fire an event, wait
for a timeout, then try the default if nothing's been received. This is
a highly complex system model and good design specifies that you never
do this unless there's a really good reason to do so.
Go with the simplest door number one.
Stephan