|
Am I just grumpy, or is this a bad idea?
My client uses a 3'rd party graphing solution for one of their intranet sites. It has worked quite well and they are very happy with it.
They wanted to add a new feature that the latest release offers, so I downloaded it and started working with it. As soon as I compile the code, I'm greeted with hundreds of errors because the vendor has changed the interface to their code.
Some parameters have had their data types changed, some methods have disappeared completely. Literally half of the code dealing with this library no longer compiles under the new version.
So, in order for us to use the new features, we first have to completely re-write the existing code just to make it work with the new version. Then, and only then, can we start taking advantage of the new features.
IMHO, this is just piss-poor programming. They should have added another interface to support the changes so that existing code would continue to work, but new code that takes advantage of the newer features could be written against a new interface.
Or am I just being unreasonable?
Mark Hoffman
Tuesday, March 23, 2004
That's not unreasonable at all. But is there any reason why the two versions of the library can't coexist?
K
Tuesday, March 23, 2004
"But is there any reason why the two versions of the library can't coexist? "
Both libraries use the same namespace, so I'm not able to include both at the same time. (C#, ASP.NET)
Mark Hoffman
Tuesday, March 23, 2004
Would it work to put your new code in a separate assembly and just reference the new graph code there?
Rob Walker
Tuesday, March 23, 2004
Thanks for the suggestion, Rob.
I was so irritated that I hadn't thought of doing that. I had to create a new project and move some objects around, but that actually worked.
Mark Hoffman
Tuesday, March 23, 2004
How many releases since you updated? It's reasonable
if you are several releases behind to expect API changes.
son of parnas
Tuesday, March 23, 2004
Actually, no it's not. It's idiotic.
Interfaces don't cost anything, so if you have to change your existing API, you create a new interface while maintaining the old one.
That's what the COM contract was all about, and even if COM is becoming passe, the concept is still valid. If you don't want to do the work required to maintain multiple interfaces, then rethink creating the new interface in the first place.
Philo
Philo
Tuesday, March 23, 2004
Amen.
K
Tuesday, March 23, 2004
Another Amen.
What's the name of the company? I will be evaluating 3rd party graphing solutions soon for a project, and I want to avoid any company that doesn't understand the concept of programming to interfaces.
Nick
Wednesday, March 24, 2004
> Interfaces don't cost anything
Actually long term they do, because you need to maintain them. You have to ensure that using the old interface doesn't break anything internally that you introduce or change. You have to make sure that if people use a mixture of both old and new that this works ok.
Wednesday, March 24, 2004
As someone just learning .NET and component programming, I'm not too sure exactly how to use an interface. My book talks about them, the whole contact thing, but not any real info on how to use them in source.
Lets say I have a component, called DatabaseIO. Should I create an interface for my DBIO class called IDBIO, in IDBIO.cs, and implement the class in DBIO.cs? How do I tell the compiler that IDBIO is the interface for DBIO? Does it do it automatically because theres an I in front of the class, or do I have to state it explicitly.
Then, when using the component in an application, how do I go about calling the component from the DLL? Do I access the class/methods through the interface (eg DatabaseIO.IDBIO.PrintStuff()), or do I access through DBIO instead...
Paul Stovell
Wednesday, March 24, 2004
Couldn't you develop a compatibility wrapper yourselves and so be able to keep the old code? If it's faster than the rewrite, of course.
Klodd the Insensitive
Wednesday, March 24, 2004
Paul,
An interface is a way of defining behaviour without exposing any implementation details.
In the 'old' COM world everything was an interface you didn't have any other way to expose functionality. In .NET the line isn't so clear as to whether you should use an interface.
If you potentially will have multiple different types of DatabaseIO objects (perhaps for talking to different databases) then it would make sense to define an interface that specifies their common functionality.
In C# you specify that DatabaseIO implements an interface using:
class DatabaseIO : IDatabaseIO
The 'I' in front of the interface name is purely convention, the compiler doesn't pay any special attention to it.
Client code has to have some means of getting hold of one of your objects. If they are just calling 'db = new DatabaseIO' then they will just call methods on db as normal: db.PrintStuff()
But if you have multiple DatabaseIO classes then you probably would want to provide a factory method somewhere
class DatabaseIOFactory
{
public static IDatabaseIO Create(String dbtype)
}
The client code calls DatabaseIOFactory.Create and gets back an interface pointer. It doesn't know (or care) which particular flavour of DatabaseIO object this is underneath.
Rob Walker
Wednesday, March 24, 2004
In introductory OO programming courses, they always teach inheritance first and don't always get to interfaces. For this reason, most developers (myself included) think in Object Hierarchy first when designing a class library. Often, interfaces are more appropriate.
However, interfaces can be a pain as well. They are an abstraction of the implementation. As Joel pointed out, abstractions leak.
For an example of interfaces gone bad, look at the standard XML libraries in Java (my favorite whipping boy). They think it's really cool that you can swap out your XML parser implementation at runtime because it's all 100% based on interfaces. However, what you get is a lowest common denominator API that sucks donkey balls. If you want any of the convenience features of the particular implementation, you get a lot of casting going on. Since the implementations must return interface references instead of object references, you cast every single time you want access to the more convenient features of the implementation.
Richard P
Wednesday, March 24, 2004
 Recent Topics
Fog Creek Home
| 
