Interfaces oversold???  
Author Message
IS dude





PostPosted: Visual C# Language, Interfaces oversold??? Top

First, I must admit that I am a C# novice and so I probably don’t have as much knowledge and experience on the subject of interface as most of you guys reading this post.

After reading a few books on C# and interface design, I still can’t see and understand the real power of interface unless of course, we are talking about interfaces as a powerful concept in OOP ‘only’ and not as a powerful concept in the general sense.

When I was first learning OOP I was quite suspicious about the ‘excellent features’ that OOP claims to be able to deliver to the world and I was right. For example, in reality OOP offers very little if any, code reuse. I am now having the same suspicion about interfaces even though I see a lot nice words used to describe them, for example ‘powerful, extensible, flexible just to name a few.

Can someone please give me some guidance on the following issues I have in relation to interface. I am trying to make sure I really understand what going on. Thanks!

1. Code reuse

Since each implementation of the interface by the subclass must be coded from scratch, there is no code reuse (unlike class inheritance), am I correct If that’s the case, why can’t the programmer just code methods for each individual class as separate components and reference them when required

There is also no indication that using interface will lead to less documentation or less work needed to explain the components. Lastly, what is the point of inheriting from methods that have no body or ‘reference types’ Are interfaces really just for ‘grouping’ classes and objects in a more organized way

2. Flexible

When it comes to flexibility, using interfaces are not necessarily any more flexible than using class inheritance. The books I have read tell me that once an interface is published, it would be a bad idea to modify it especially if you already have many clients implementing the same interface.

So ultimately, the burden of producing an application with a clear logic and flexible design rests on the shoulder of the programmer and that interfaces or even the programming language might have absolutely nothing to do with the good design.

3. Powerful

Is interface a powerful concept only in the OO world or OO sense Does anyone know any good articles that clearly demonstrate the true power of well designed and implemented interfaces

4. Enforcing standards

Standards can be enforced through the use of clear documentation, diagrams and naming conventions. In fact, clear documentations are the basis of any good design anyway. . Are there any compelling reasons why you would want to enforce standards through the use of interfaces

What exactly are the ‘practical’ benefits anyway By practical I mean for example, the system would be able to better manage the memory or compile the code more efficiently I am thinking that the benefits must somehow relate to how the computer manages or processes ‘stuff’ because for us humans, the logic behind this whole interface stuff isn’t new or particularly fascinating.



Visual C#6  
 
 
Paul Louth





PostPosted: Visual C# Language, Interfaces oversold??? Top

1.Interfaces are used for specific reasons.  Code-reuse isn't one of them.  They're used to define a standard method of interacting with a sub-class which implements the interface.  If a programmer just codes methods for each individual class then another method which expects an object of the type IMyInterface can't then deal with it.  To handle them they would have to either use reflection, or have multiple versions of each method to handle the various different types, and wouldn't be extensible.

2.It depends on what uses the interface.  If the interface is used by multiple remote clients, then you will struggle to modify them at a later date.  However that is the same for classes too.  If they're used in a single app-domain then modification should be fairly simple as the compiler will find any problems.

3.I think it's widely accepted that interfaces allow clear contract driven development.  I don't have any links to hand to be honest, it's something I don't really need referrence on.

4. Standards aren't enforced through interfaces, contracts are.  I don't subscribe to the theory of creating an interface for every class you write.  I personally only use interfaces when I need to communicate across app-domain or library boundaries.  I will also use them if I have created an abstract class without any implementation details.

Try to think of them as the ultimate lightweight base-class.


 
 
IS dude





PostPosted: Visual C# Language, Interfaces oversold??? Top

hi,

so, how exactly do interfaces promote code reuse since the classes that inherit the members must code the members from scratch


 
 
Paul Louth





PostPosted: Visual C# Language, Interfaces oversold??? Top

Did you read what I said They do not promote code re-use.
 
 
Matthew Watson





PostPosted: Visual C# Language, Interfaces oversold??? Top

One thing worth pointing out is that - in C# - interfaces are the only way to achieve any kind of multiple inheritance.


 
 
IS dude





PostPosted: Visual C# Language, Interfaces oversold??? Top

Of course I have read what you said. Almost every article and book i have read says that interfaces promote code reuse. I just want to know whether other people believe that interfaces do indeed promote code reuse.
 
 
Mark Benningfield





PostPosted: Visual C# Language, Interfaces oversold??? Top

Hello All.

IS dude:

The primary benefit of Interfaces (like much of OOP) is in regard to library code. If you're writing code that other programmers will use, then what Interfaces do is ensure CONSISTENT BEHAVIOR. The details of how that behavior is accomplished are hidden, and from the consumer's point of view, irrelevant. But, if you are writing code that implements a particular Interface, then consumers of your code know that it will behave in certain dependable ways and dependably do certain things.

Like most industries, the Big Dogs drive the truck, and they use lots of programmers to each write small portions of the project, and so the model they use is library code. From this perspective, OOP is a fabulous (and quite natural) develpment. And so, the industry moves in that direction.

That's not to say that OOP doesn't have any benefits for the programmer writing stand-alone application code. Encapsulation usually results in much cleaner logic and a lot more sensible program flow. Inheritance can be a real time-saver as well. Polymorphism is also an extremely useful aspect of OOP, in any situation. From this point of view, as a consumer of whatever Interfaces exist in the library code that one would call, the Interface guarantees that the library code will behave according to the rules set forth. And, the major benefit of OOP to the stand-alone app programmer is the utility provided by all of the library code that is written according to OOP (Hooray, .NET).

From the stand-alone author's point of view, unless (as Paul mentioned) the code needs to communicate with other entities, Interfaces don't present much practical utility, if you discount style and sensiblity.



 
 
Paul Louth





PostPosted: Visual C# Language, Interfaces oversold??? Top

 
Of course I have read what you said. Almost every article and book i have read says that interfaces promote code reuse. I just want to know whether other people believe that interfaces do indeed promote code reuse.

The only area where they may lead to code re-use is where you may have multiple classes that implement the same interface, and because of that they're more likely to work with other classes that work with that interface.  But to say they 'promote' code re-use is wrong in my opinion. 

They promote consistency, contract driven development, and well formed method prototypes.


 
 
PhilipRieck





PostPosted: Visual C# Language, Interfaces oversold??? Top

Of course I have read what you said. Almost every article and book i have read says that interfaces promote code reuse. I just want to know whether other people believe that interfaces do indeed promote code reuse.

Not that I don't believe you, but I'd be interested in what books and where - I've never heard of interfaces being sold as a way to foster code reuse. It has been claimed that OOP promotes code reuse (and that's another discussion), but not the "interfaces" aspect.


Also:


When I was first learning OOP I was quite suspicious about the ‘excellent features’ that OOP claims to be able to deliver to the world and I was right.

I normally wouldn't respond to questions that already assert the answers. And I'm not sure why you bring up OOP in general. If you want to discuss the merits of OOP in general, be prepared for more of a holy war than a discussion.

Even so, here's my two cents. Bear in mind that this is under the assumption that we are discussing interfaces as a concept in C#, not OOP vs non-OOP.

1. Code Reuse
Code reuse isn't the way to look at it. Interfaces are for contract definition. They allow polymorphism in a compile-time strongly typed language without forcing inheritance of implementation.

2. Flexible
Your question under flexible seems self-answering. Yes, good design trancends interfaces and even programming language. I would agree with that quite strongly. However, a good design is shaped by and constrained by the languages and tools it specifies. Interfaces aren't a replacement for good design - that much is obvious. They are simply another tool to enable a good design.

3. Powerful
"Powerful" seems to be a loaded term. For one thing, I would say Interfaces are nearly essential in c#. Since c# is strongly typed at compile time and doesn't allow for multiple inheritance they simply must be available to prevent horrible hackery.

Beyond this, (and even in c++ which does allow multiple inheritance) they are quite useful as a way to define a contract (service), and then allow other code to provide that service with an implementation (component) at runtime. You can distribute the interface (by distribute I don't mean only "external people", but outside the source code itself) without defining or exposing implementation. (Please note this is c# we're talking about, not lisp or some other language x where they may not be as useful or available)

In more dynamic languages, when you call " obj.FooBar()", (or send the message "FooBar" to "obj", however you prefer to say it) you see a dynamic interface - you are saying the instance "obj" should support message "FooBar". Instead of demanding the interface at compile time, you are specifying it at runtime.

In non OO arenas, interfaces are also essential. For example, I'd say that the HTTP specification is an interface. By implementing it, anything that can utilize that interface can use your component.

4. Enforcing standards
I'm not sure what you mean - sure coding standards can be enforced via naming conventions and documentation, but this is a completely unrelated concept to an interface. Interfaces are about defining a run-time and compile-time contract without specifying an implementation. Not defining code standards.


What exactly are the ‘practical’ benefits anyway By practical I mean for example, the system would be able to better manage the memory or compile the code more efficiently I am thinking that the benefits must somehow relate to how the computer manages or processes ‘stuff’ because for us humans, the logic behind this whole interface stuff isn’t new or particularly fascinating.

For your definition of "practical", they have none. The benefits relate to enabling design patterns and OOP constructs that would be impractical or impossible without it. Wether or not using these patterns benefits you is your call alone.


 
 
TechNeilogy





PostPosted: Visual C# Language, Interfaces oversold??? Top

I disagree with the general trend in this thread in that I think interfaces can help support significant code reuse on the downstream side.  This is especially true where classes implement multiple interfaces.

For example, the fact that a class can implement two interfaces (say IA and IB) means that downstream code designed to use interface IA can support all classes which implement IA, independent of any knowledge of either IB or non-interface publics of IA.  This can significantly increase the re-useability of IA-users.

Of course, there's no magic here, the re-useability is a side effect of the kind of design that contract-based progamming makes possible.  The magic is in the factoring.

Re-use is not guaranteed, but it is significantly aided.

-Neil


 
 
Hatzi74





PostPosted: Visual C# Language, Interfaces oversold??? Top

Hello...

There is another point to interfaces. They allow for an extremely loose coupling of your systems. You can easily swap out 2 classes if they implemnt the same interface. This really comes in handy when you want to test your code. Also there is the option to create a Mock from an Interface to help you test your business Object layer for example. If you want to test against a DB you need to make sure there is the correct data, so your tests will run. If you use Interfaces, you can "shove in" some "mocked" objects from the interface and define a behavior on them.



 
 
IS dude





PostPosted: Visual C# Language, Interfaces oversold??? Top

First, thank you all every much for helping me out with my questions, - THE PARAGRPHS IN BLUE ARE QUOTES..

Not that I don't believe you, but I'd be interested in what books and where - I've never heard of interfaces being sold as a way to foster code reuse. It has been claimed that OOP promotes code reuse (and that's another discussion), but not the "interfaces" aspect.

Most of the articles and books I have read do say that code-reuse is one of the merits / benefits you get from using interfaces. Now, I am not saying that the way they mention code reuse as a benefit is right or wrong, good or bad. But when I was reading these articles / books I kept asking myself, what exactly do they mean by that This is the same question I have asked myself after having read a few books on the subject of OOP. I have doubted my own judgments by thinking that I must have missed something quite important, something that is only accessible to the real experts of OOP.

Many people I believe (and not just the beginners) think it would be quite natural to relate interfaces to OOP in general (and I don’t see anything wrong with this) because the terms always appear together in books and articles and more importantly, they are promoted in a way as though they cannot be treated separately and must be understood under the same OO paradigm. Again, I am not suggesting whether this is good or bad, right or wrong, but it can lead to a lot of confusion especially when you are trying to work out ‘how’ to apply these concepts ‘properly’ to your code and at the same time, take into account the constraints imposed on the you by the programming language itself.

For example, inheritance is a great concept but you can only use it once on one class. Interface is also a great concept but again it is not as straight forward as it seems since you must spend lots and lots of time on planning and thinking in advance otherwise the code structure could become impossible to modify.

You can easily find the kinds of article I am talking about if you search Google (but I don’t want to name any names here). I am not that inexperienced in C#, but just never worked on a very large project and so never had the opportunity to experience the true power of OOP and interfaces. Paul mentioned that there would be code reuse if

you have multiple classes that implement the same interface, and because of that they're more likely to work with other classes that work with that interface. To me, this point sounds closer to reality but then it seems that you can only get this kind of benefit when the scale of the project you are working on is of decent size. An Interface is indeed useful as a concept but in order to reap the benefits in coding you would still need to do lots of planning and thinking in advance.

 The primary benefit of Interfaces (like much of OOP) is in regard to library code. If you're writing code that other programmers will use, then what Interfaces do is ensure CONSISTENT BEHAVIOR.

 I am assuming that by ‘consistent behavior’ you mean establishing some kind of standard across the entire project / application design Now, why would you want to create this additional layer of code using interfaces if you can just code the sub classes as separate classes I thought that having this extra layer of code would force all the subclasses to implement the same members. So in reality isn’t this is where all the problems associated with inflexible design and code originates from

 I normally wouldn't respond to questions that already assert the answers. And I'm not sure why you bring up OOP in general. If you want to discuss the merits of OOP in general, be prepared for more of a holy war than a discussion.

I have answered my own question as a way to clear up my own thoughts and to see if there are any strong objections and ‘why’. I am not doing this to deliberately provoke or offend anyone who has applied OO principles on projects (especially large scale projects) and firmly believes in the merits of OOP .

I bring up OOP in general because interfaces are normally treated as an integral part of OOP. I am not saying that interfaces ‘IS’ OOP but there is a very strong bond between the two concepts; at least this is the ‘perception’ I get from reading books and articles. Is my perception wrong

There is another point to interfaces. They allow for an extremely loose coupling of your systems…..

I also have a problem with the concept of loose coupling. Here is a brief explanation on why a loosely coupled design fits good OO practice:

“Loosely coupled designs allow us to build flexible OO system that can handle change because they minimize the interdependency between objects” – Head First Design Patterns, 2004.

Okay, I agree with the authors completely, but still I have the following questions:

1. I just can’t see how interfaces can really ‘loose things up’ when all they do is forcing the subclasses to implement every member on their list. Compare to inheritance they are probably more flexible but their flexibility comes from the fact that the programmer needs to write the code from scratch. Somehow I just can’t see why this would be a particularly attractive approach for allowing loose coupling.

2. In ‘Programming .NET components’ (2nd Edition), the author Juval Lowy, strongly discourages programmers to create interfaces with only one member. The idea is to factor out an appropriate number of common attributes, that ‘appropriate number’ according to the author is 3 to 5.

Having a one member interface clearly defeats the purpose of using an interface because interfaces are there to support abstraction and allow programmers to exploit polymorphism. However, having too many members can be an extremely bad idea because this can easily lead to inflexible code / class structures. Now, everything these authors say makes sense to me.

What I don’t understand is that we could certainly conceptualize and plan our components without interfaces. Abstractions or ‘stereotyping is natural to us humans but I think, only as concepts. When we apply these concepts to coding, they seem superfluous.

The computer couldn’t care less whether or not we use interfaces. As the following quote from Paul suggest: For your definition of "practical", they have none. The benefits relate to enabling design patterns and OOP constructs that would be impractical or impossible without it. Whether or not using these patterns benefits you is your call alone.

Also, does anyone have any problem with way in which some authors and experts try to describe interface ‘contract’ as though their purposes are identical to a real world legal contract

Real world contracts are created from ‘necessity’. For example, a landlord asks a lawyer to draft a tenancy agreement for him so that he could use it to minimize his risk if and when he happens to come across an irresponsible tenant. Most, or in fact all real world contracts are created because of ‘need’. I know that an interface contract ‘behaves’ like a real world contract in that they bind together two entities that agree to follow a common set of rules and guidelines.

But what is the ‘real necessity’ for creating this binary contract (interface) in the first place Do we create one just because it is simply a good OO practice to do so Is this ‘contract’ a concept for human consumption ‘only’ and again, really has nothing to do with the computer system after all


 
 
Paul Louth





PostPosted: Visual C# Language, Interfaces oversold??? Top

One thing, I don't think interfaces "allow for an extremely loose coupling of your systems.". That's just not true, because by consuming an interface you're bound by it's contract (its member names, paramater orders, parameter types, etc), so therefore you're tightly coupled to it because you're dependant on it.

Loose coupling comes from message-based systems, XML data with schemas etc. Where two systems can change over time without adverse affect on the other.


 
 
IS dude





PostPosted: Visual C# Language, Interfaces oversold??? Top

One thing worth pointing out is that - in C# - interfaces are the only way to achieve any kind of multiple inheritance.

What you are saying is indeed true. But to be honest, I find the idea of achieving multiple inheritance via interfaces quite misleading. The reason is simple, interfaces and inheritance are NOT the same thing.


 
 
Mark Benningfield





PostPosted: Visual C# Language, Interfaces oversold??? Top

The primary benefit of Interfaces (like much of OOP) is in regard to library code. If you're writing code that other programmers will use, then what Interfaces do is ensure CONSISTENT BEHAVIOR.

I am assuming that by ‘consistent behavior’ you mean establishing some kind of standard across the entire project / application design Now, why would you want to create this additional layer of code using interfaces if you can just code the sub classes as separate classes I thought that having this extra layer of code would force all the subclasses to implement the same members. So in reality isn’t this is where all the problems associated with inflexible design and code originates from

Well, first off, that's a rather wild assumption. The consistent behavior is ensured by the object to the consumer, in that -- since it implements a known interface -- the capablilities of that interface are guaranteed to be available on that object.

What I don’t understand is that we could certainly conceptualize and plan our components without interfaces. Abstractions or ‘stereotyping is natural to us humans but I think, only as concepts. When we apply these concepts to coding, they seem superfluous.

The computer couldn’t care less whether or not we use interfaces. As the following quote from Paul suggest: For your definition of "practical", they have none. The benefits relate to enabling design patterns and OOP constructs that would be impractical or impossible without it. Whether or not using these patterns benefits you is your call alone.

Also, does anyone have any problem with way in which some authors and experts try to describe interface ‘contract’ as though their purposes are identical to a real world legal contract

Real world contracts are created from ‘necessity’. For example, a landlord asks a lawyer to draft a tenancy agreement for him so that he could use it to minimize his risk if and when he happens to come across an irresponsible tenant. Most, or in fact all real world contracts are created because of ‘need’. I know that an interface contract ‘behaves’ like a real world contract in that they bind together two entities that agree to follow a common set of rules and guidelines.

But what is the ‘real necessity’ for creating this binary contract (interface) in the first place Do we create one just because it is simply a good OO practice to do so Is this ‘contract’ a concept for human consumption ‘only’ and again, really has nothing to do with the computer system after all

Remember, source code is for human consumption. Coding concepts, software design theories, all of that sort of thing, it's all for human use and perception. Processors know 1's and 0's, the rest of it is for our benefit. So the interface does not exist as such in binary. Only in source code. Once in binary, it consists of a series of entries in a vtable or something.

So, yes, an interface is a "real" contract. Between the author of the object and the consumer of the object. It says that the object will behave according to the rules of the interface, which, yes, is a human concept. OOP is a human concept. As such, it isn't perfect, and quite obviously, not everyone agrees with every part of it, but it beats the pants off of the old GOTO spaghetti-sprawl.

Now, as far as whether or not all of the "buzzwords" are true, surely you realize that they rarely ever are. Buzzwords always make an assertion without providing a context, so they are meaningless on their face. Once you provide the context, then they make much more sense, but of course, then they are no longer buzzwords.

For example, "Promotes Code Re-Usability" is absolutely meaningless to any reasoning person. However, once you add the context, "...indirectly by making it easier to exchange software entities that implement the same interface." -- it makes much more sense. Note, however, that it doesn't say "Provides" code re-usability, but "Promotes." Meaning that it doesn't automatically make code re-usable, but that it adds to the ability to make code re-usable.

Correct me if I am wrong, but I gather from the subject line of your post is that you question whether interfaces are as good a tool as many think they are. Well, the short answer is yes, they are, if they are used for the right job. A claw-hammer is an excellent tool, but it tends to make a mash out of brain surgery. An interface is a communication prototcol. A way of communicating with specific, definite rules. If the job is to communicate between software entities, then interfaces are an excellent tool.

HTH.