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.

Use of interfaces

Some say we should use an interface,if we are going to have multiple implementations.But one use of interface is ease of unit testing.Say,I am calling a webservice,i can instead work with an interface which will help in testing.
So,would you never use an interface if only one implementation?
anon
Saturday, May 05, 2007
 
 
If you are sure that you'll have only one implementation, there's no need for an interface.
And it's not impossible to add it later either.
Pakter
Saturday, May 05, 2007
 
 
A mock implementation for testing is a valid second implementation that might lead you to create an interface.
Mike S Send private email
Saturday, May 05, 2007
 
 
Depends on the problem. If I'd feel that I'd need to stay open for extension (with respect to the OCP), I'd prepare myself for dependency inversion and use the interface to ensure future entensibility. If not, not :)
rc Send private email
Tuesday, May 08, 2007
 
 
"A mock implementation for testing is a valid second implementation that might lead you to create an interface."

Seconded.


a non-exhaustive list of when to consider interfaces:

You find yourself writing the same method signatures with the same semantics on two or more classes;

You want clients to know absolutely nothing about the class other than what operations can be performed on the class;

You want to model your application based upon service boundaries rather than class boundaries, even if behind the scenes a single class may implement more than one service;

You want to provide for extensibility at configuration time (e.g. plugins, 'service locator' models) even if you only ship a single implementation yourself;

You are refactoring implementations into multiple classes for maintainability, you can hide a refactoring behind an interface wall and an adapter or facade.


However you don't have to scatter interfaces all over if you're not actually using them.  The meaning of the word 'interface' implies some sort of natural boundary to which other things interact.  This can apply when you are creating a library or service that is being maintained as a conceptually separate entity.  It may not necessarily apply when everything is mashed into the same project, or when you have complete control over who and how is accessing your library.

In the original case, interfaces seem to be common with web services, in that the 'service' is defined by the interface , which might be implemented by a web service backed proxy, or by a mock object, or by a "local" version of the service, all of which the client doesn't generally care about.
Dan Fleet Send private email
Tuesday, May 08, 2007
 
 
if you use any decent refactoring tool, extracting the interface from its class is trivial.  So even if you don't start with interfaces, you can still land back on your feet if you need one at a later date.

Some techniques (like dynamic proxies) work only with interfaces and not classes (see XFire for Web Services without any wsdl coding)

regards,

-Vladimir

Tuesday, May 08, 2007
 
 
"only one implementation" -- i.e., you're never going to release a newer version to fix bugs?

At least in C++, the use of interfaces can alleviate much of the pain involved in making sure that implementation details don't "leak" into the interface in ways that make it impossible to seamlessly substitute one release (implementation) for another.

See http://www.gotw.ca/publications/mill05.htm

 and

http://www.gotw.ca/gotw/024.htm
BillT Send private email
Wednesday, May 09, 2007
 
 
We might also introduce an interface to manage the direction of dependencies between components.
Stan James Send private email
Wednesday, May 09, 2007
 
 
I try to use interfaces to present the 'public' face of whatever API I'm creating to its users (when I say 'users' here I'm not referring to people, rather Im referring to code that uses this object - mostly that just means code in the next layer up in the app, or it could be a different app if I'm writing a library etc...).

So the interface is nice and clean and it only has methods that are interesting to its users.

The actual object(s) implementing that interface otoh often have a bucketload more stuff that is acting as plumbing and so forth for the object and bolting it together with other stuff in this layer, and for the use of other libraries that work with it (for example a multitude of setters that might be invoked by Hibernate or Spring but are of no concern to the objects user), and this is all ugly implementation details that I don't want to expose to the users - who would generally not even know what concrete class was implementing the interface they are working with.

Speaking of which there may be more than one type of user for the object, and that may well mean multiple interfaces that expose different things to different users depending on their role in interacting with it. For example one interface might be concerned with the objects purpose in the problem domain, another might be concerned with aspects of persistence and so on.

Hmm. I haven't really put this very clearly eh? Well I hope I've at least got across the idea that its about more than just being able to substitute or mock implementations.
AH
Thursday, May 24, 2007
 
 

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

Other recent topics Other recent topics
 
Powered by FogBugz