General question on using Interfaces

  • Thread starter Thread starter Bob Weiner
  • Start date Start date
B

Bob Weiner

I have a few dll's that return their own version of Account objects. In the
asp code I am writing now I would like to define an interface, called
IAccount, and convert each of these objects ( dll1.Account, dll2.Account...)
upon return so I can deal with them synonymously.

The type conversion is not allowed and I'm not sure how to work around it.

I'm using C# in VS2005.

Thanks, bob
 
Bob Weiner said:
I have a few dll's that return their own version of Account objects. In the
asp code I am writing now I would like to define an interface, called
IAccount, and convert each of these objects ( dll1.Account, dll2.Account...)
upon return so I can deal with them synonymously.

The type conversion is not allowed and I'm not sure how to work around it.
Click to expand...

What do you mean by "the type conversion is not allowed"? Do the
various Account types actually implement IAccount?
 
No, the dll's were implemented at different times to do different things.
One gets user objects from AD; another queries user information from SQL
server. Neither are aware of the ASP page that I'm putting together now.

As part of my current page I want to make a usercontrol to that will take an
Account object from either dll and display the user's information. Of
course AD.Account != SQL.Account (although they have a common set of
properties) so it seems like using an interface would be the best approach.

If this isn't possible, what is the best strategy? Certainly, I don't need
a separate usercontrol for each dll, do I?

bob
 
Bob Weiner said:
No, the dll's were implemented at different times to do different things.
One gets user objects from AD; another queries user information from SQL
server. Neither are aware of the ASP page that I'm putting together now.

As part of my current page I want to make a usercontrol to that will take an
Account object from either dll and display the user's information. Of
course AD.Account != SQL.Account (although they have a common set of
properties) so it seems like using an interface would be the best approach.

If this isn't possible, what is the best strategy? Certainly, I don't need
a separate usercontrol for each dll, do I?
Click to expand...

Using an interface does indeed sound like the right approach - but the
types have to actually *implement* the interface. You can't cast to the
interface just because it happens to have all the members.

Can you change the source of the DLLs just to implement the interface,
recompile, and then run?
 
No, the dll's were implemented at different times to do different
things. One gets user objects from AD; another queries user information
from SQL server. Neither are aware of the ASP page that I'm putting
together now.

As part of my current page I want to make a usercontrol to that will
take an Account object from either dll and display the user's
information. Of course AD.Account != SQL.Account (although they have a
common set of properties) so it seems like using an interface would be
the best approach.
Click to expand...

If you aren't changing the original types so that they are declared as
implementing the interface, then you can't use the interface directly
on the classes. Even implicit implementations of interfaces will only
work if the class is specifically declared as implementing the
interface.
If this isn't possible, what is the best strategy? Certainly, I don't
need a separate usercontrol for each dll, do I?
Click to expand...

I suppose one possibility would be to create a new proxy class, rather
than an interface. You'd wrap an instance of one of the other classes
in the proxy class and then pass the proxy instance around. The proxy
instance would then have code to explicitly handle the shared methods
or properties internally, when the duplicated proxy versions are called
on the proxy.

You could implement such a proxy using an abstract class with concrete
derived classes for each control you want to wrap, or with an actual
interface (e.g. the IAccount you've already declared) with a different
proxy class that implements the interface for each DLL you want to
support.

There are actually lots of other alternatives, but I think that one of
the above options seem closest to the behavior you're already trying to
implement.

Pete
 
Thanks! Good suggestions, both.

I'm always looking for the "right" answer instead of just forging ahead.
Certainly for this app, I can import the source directly.

The proxy idea would help with extensibility so I could plug in other dll's
later. Then again, that may be naive thinking - each dll will probably be
different enough to require some rework. Would this approach be the
provider model I hear about from MS?



bob



Bob Weiner said:
No, the dll's were implemented at different times to do different things.
One gets user objects from AD; another queries user information from SQL
server. Neither are aware of the ASP page that I'm putting together now.

As part of my current page I want to make a usercontrol to that will take
an Account object from either dll and display the user's information. Of
course AD.Account != SQL.Account (although they have a common set of
properties) so it seems like using an interface would be the best
approach.

If this isn't possible, what is the best strategy? Certainly, I don't
need a separate usercontrol for each dll, do I?

bob
Click to expand...
 
Thanks! Good suggestions, both.

I'm always looking for the "right" answer instead of just forging
ahead. Certainly for this app, I can import the source directly.

The proxy idea would help with extensibility so I could plug in other
dll's later. Then again, that may be naive thinking - each dll will
probably be different enough to require some rework.
Click to expand...

Well, I suppose that depends. If the DLLs each provide an API that is
identical, in a way that would have made you think you could just use
an interface, then I'd think the proxy approach would be simple. It
would always just be a matter of taking the instance of the class
implemeted in the DLL, and calling the appropriate methods or
properties from the proxy class. All of the proxy classes would look
the same, even though they'd all be specific to the DLLs.

If your DLLs are somehow different, then I don't see how an interface
could have applied anyway. The whole point of an interface is that
each implementor provides exactly the same identically implemented API.

That said, I can certainly imagine a scenario where each DLL provides
almost the same API, but with trivial differences that would prevent an
interface from working even if you could just copy the DLL source into
your project. In that case, using a proxy would allow you to not only
wrap the DLL without copying the source to your project, it would
provide a convenient location to handle whatever API conversion needs
to happen.

It all comes down to just _how_ different each DLL is. But if each DLL
is similar enough that you can represent the functionality with a
single interface (whether or not the DLL itself exposes the exact same
interface), then they are similar enough for a proxy to work.
Would this approach be the provider model I hear about from MS?
Click to expand...

I don't know. I don't know what the "provider model" that you're
hearing about from MS is. :)

Pete
 
Back
Top