|
Separating Interface from Implementation
.NET is my (new) toolbox. OOP has historically (9 out of 10 times) been the methodology I strive for ... not necessarily for reuse (haven't seen this happen too much) but for ease of use in the first place by multiple brains who understand OOP.
Anyhow, a common desire by the architectural elite (ie, those who abstract VERY well) is the separation of implementation and interface. With respect to .NET, "thou must first create the interface and then implement it" ... I'm curious, the frameworks I build are internal (we ship a product not an API) ... so, if my classes are defined/maintained from UML class diagrams ... how do I benefit with an "extra layer" of interface code as opposed to straight implementation (outside of the 'ease-of-read')?
Tom
Wednesday, December 17, 2003
Multiple classes can implement the same interface, and classes can implement more than one interface, allowing you to practice the mixin style instead of full multiple inheritance.
Just me (Sir to you)
Wednesday, December 17, 2003
You can replace your objects with other objects that implement the same interface. This doesnt seem like such a big deal until you realise that this can make code much more testable...
I've babbled before about this kind of thing: http://www.lenholgate.com/archives/000145.html
Len Holgate (www.lenholgate.com)
Wednesday, December 17, 2003
I agree with Len. It also prevents you from ending up with strange interfaces that burden other classes.
Lou
Wednesday, December 17, 2003
Another way to look at this is that this is equivalent to separating specification from implementation. This separation helps ensure a robust design. If you have no implementation it's very hard to build in dependencies on implementation. Also, it helps ensure that the interface is both necessary and sufficient for clients to use the implementation correctly.
Observer
Wednesday, December 17, 2003
Interfaces also help when you have orthogonal concerns.
For example, you may have a Customer object. This needs to support Customer stuff (name, address, etc.) but it also knows how to serialize itself. The serialization part is completely separate from the meat of the customer stuff. If you factor the serialization piece out into a separate interface, you can create a whole bunch of "serializable classes".
Chris Tavares
Wednesday, December 17, 2003
Perhaps not really addressing the "why", but "when" you start doing this you'll find your code is a lot cleaner.
Walter Rumsby
Wednesday, December 17, 2003
The .NET teams did not practice what was preached; in particular, the ASP.NET system would've been much much better off if I'd been seeing things like IWebControl and IWebPage instead of Control and Page. There's a lot of lost flexibility there.
Arrrgh!
Brad Wilson (dotnetguy.techieswithcats.com)
Wednesday, December 17, 2003
Why would IWebControl and IWebPage be better than Control and Page?
Wednesday, December 17, 2003
I'm curious, for those of you that regularly create seperate interfaces and implementations...
How do you normally construct the classes? If my boundry between layers and classes are interfaces, I have to have something that actually constructs the implementation classes and returns the interface, so as to hide the details.
Whenever I try and religiously use interfaces, I find I end up with Factory pattern concrete classes all over the place that do nothing more than create other classes and return an interface to the new object.
Have you found better approaches?
OccamsRazor
Wednesday, December 17, 2003
The places where I've used interfaces extensively:
COM: you have to use interfaces, period. The factory pattern is built in in the form of CoCreateInstance, so no extra coding there.
.NET: I'm working on a plug-in based architecture now, and of course the plug-ins implement interfaces. I use reflection to walk the assembly, and use the .NET System.Activator class to create my concrete objects.
Generally I find my factories are a lot more sophisticated than:
Interface1 *factory1() { return new Concrete1(); }
Interface1 *factory2() { return new Concrete2(); }
There's some kind of dictionary lookup, or walking of a directory, or registry key, or something to map what I want to the actual class that gets created.
I have a sneaking suspicion this did not answer your question. :-)
Chris Tavares
Wednesday, December 17, 2003
"Why would IWebControl and IWebPage be better than Control and Page?"
It has nothing to do with specifics. It has to do with whether you develop against a contract, or develop against an implementation. There are implementation details about both Control and Page that I am not particularly fond of, but since any control must derive from Control, then I'm stuck with them.
Brad Wilson (dotnetguy.techieswithcats.com)
Wednesday, December 17, 2003
And, honestly, if you don't get that, you don't get interfaces. It's the most fundamental question about _why_ someone would want to develop against interfaces instead of implementations.
Brad Wilson (dotnetguy.techieswithcats.com)
Wednesday, December 17, 2003
I'm a Java guy, but I think my comments apply.
Any time you make the comment that you use something "religiously" a little warning bell goes off in my head that seems to think you're overusing a pattern. Interfaces are good, but like all things they have good and bad uses. The only "must use " for interfaces in my book so far ...
- any set of utility classes that operates on interfaces tends to be more reusable
- packages written to accept and return interfaces tend to be more useful & maintainable
Beyond that interfaces vs abstract classes I don't get too excited about. Rule of thumb for me is abstract classes are for common code, interfaces are for types. But if it makes for more concise & readable code, ithe rule goes out with the bathwater. I can always extract an interface later if the need arises. So far, the need hasn't arisen.
John Adams
Wednesday, December 17, 2003
Simply put, developing against interfaces allow components to be loosely coupled. You aren't mandating an implementation, you're mandating a contract. Particularly in the case where you're developing a development library -- like ASP.NET -- you want to give the developer maximum flexibility.
Brad Wilson (dotnetguy.techieswithcats.com)
Wednesday, December 17, 2003
> How do you normally construct the classes?
That depends. The use of interfaces doesnt necessarilly always require the ultimate runtime flexibility of the factory pattern. You still get lots of value even if you explicitly wire up the objects somewhere in the app. The value of the interface is that you CAN replace the implementation. You dont have to write the code right now that means you MUST be able to replace the implemenation.
If you need a factory use a factory, if not, just wire up the objects as usual. When you find that you need to be able to replace an implementation at runtime you can just slip a factory into the mix; if you didnt use interfaces to start with it tends to be harder to do that...
Len Holgate (www.lenholgate.com)
Thursday, December 18, 2003
>Any time you make the comment that you use
>something "religiously" a little warning bell goes off in my
>head that seems to think you're overusing a pattern.
>Interfaces are good, but like all things they have good
>and bad uses. The only "must use " for interfaces in my
>book so far ...
Totally agreed, and I didn't mean to imply that it was an all or nothing affair. I just meant to say that when I use them extensively I haven't found any other reasonable alternative for creation than factory patterns. Reflection notwithstanding in some type of plug in architecture as was mentioned.
As for using them but doing implementation coupling anyway by directly instantiating classes...I do that a lot by not bothering to create a factory, but still passing interfaces around after creation to keep things "largely" decoupled. I imagine most of us do that in the real world.
OccamsRazor
Thursday, December 18, 2003
Agree with John and OccamsRazor...
I like to Do The Simplest Thing That Will Possibly Work, so for unit testing purposes I find that about 30% of my classes require an interface.
Scot Doyle
Thursday, December 18, 2003
 Recent Topics
Fog Creek Home
| 
