How do interfaces work and How to use them in practical programming [closed]

Closed. This question needs details or clarity. It is not currently accepting answers.

---

Want to improve this question? Add details and clarify the problem by editing this post.

开发者_如何学Go

Closed 6 years ago.

Improve this question

I started my programming life not long ago. It is said that if you combine data and algorithm together, then you got a program. That is exactly what I do now, yet I hear these theories:

• Build for today, design for tomorrow
• Before coding, make each module as clear as possible
• Your code should not be understandable by just a handful of people

• Prepare for predictable changes

  All in all, I come across no theories about interfaces. I wonder where and when to use interfaces to meets good standards.

  Maybe you know a lot. Then give me some tips! Examples are wonderful!

---

• Interface (computer science)
• Application programming interface

Sorry if the answer is very general, but it's as general as the question.

---

Interfaces: Why can't I seem to grasp them?

Understanding interfaces

---

Interfaces are useful when you are designing your code to be highly testable. If you're referencing interfaces instead of concrete classes, it's about a million times easier to test them.

Interfaces are also useful when you are defining behaviours that should be standard across an application or a framework. Think about things like IDisposable and INamingContainer that have varying degrees of usefulness in many places. IDispose.Dispose() is used to release unmanaged resources. The "how" is up to the implementer but the fact it exists signifies something to the outside world.

---

In Java terms, the JDBC API is an excellent example of the power of interfaces. The DB vendors supplies their own JDBC driver (which is just a concrete implementation of the JDBC API) and you can just program uniform JDBC code without worrying about compatibility with tens of different databases.

---

When you learn to drive, you are concerned about the interface of the car (the pedal, the brakes, the steering wheel), not its implementation: disk brakes and drum brakes are accessed through the same interface (the pedal). You are not concerned about their nature, how they are driven etc... unless you are a mechanic. When you drive, you just access them by their generic interface. Performance can be different, but behavior is not.

There are two contral issues when programming, one technical, the other business-oriented

1. managing complexity. Complexity comes from number of entities and number of interactions among these entities.
2. parallelizing development tasks to achieve the release before your competitor, possibly with a better product (although it is not required these days).

Dealing with interfaces-oriented programming is a good method to solve both problems. The more you are able to hide complexity behind a funnel of a well-defined, generic interface, the less interactions you have (because you now see a large number of entities as a single, whole, complex entity no longer made of subparts), and the better you can parallelize development tasks, because everybody solves the problem he is competent in, without having to mess with a field he is not.

---

If you have read all this jargon, but not yet found out what they mean, then you are not reading all the right books.

Try:

1. Robert C. Martin (unclebob)'s Clean Code.
2. Michael Feather's "Working effectively with Legacy Code".

I know it helped me a lot.

Cheers

---

i try to simplify with a pragmatic example:

////////////////////
//VERY(!) simplified, real forums are more complex.
public interface ForumActions{

  /** @throws UserDisallowedException, email is not allowed to post. */
  Thread startThread(String email, String threadName, String description)
    throws UserDisallowedException;

  /** @throws UserDisallowedException, email is not allowed to comment. */
  void commentThread(String email, Thread thread, String comment) 
    throws UserDisallowedException;
}

///////////////////////////
//IMPLEMENTATION 1
public class StackOverflowForum implements ForumActions{

  /**
   * @param email Email of poster, which must have been registered before.
   *
   * @throws UserDisallowedException The mail address is not registered 
   */
  public Thread startThread(String email, String threadName, String description) 
     throws UserDisallowedException {

    if(isNotRegistered(email))
      throw new UserDisallowedException(...);
    ...
    return thread;

  }
}
...
}

///////////////////////////
//IMPLEMENTATION 2
public class JavaRanchForum implements ForumActions{

  /** 
   *  @param email Email of poster, which mustn't have exceeded a posting-limit per day.
   *               This way we protect against spammers.
   *
   *  @throws UserDisallowedException, the mail was identified as a spamming origin. 
   *        is mandatory for posting threads.
   */
  public Thread startThread(String email, String threadName, String description) 
     throws UserDisallowedException {

    if(isSpammer(email))
      throw new UserDisallowedException(...);
    ...
    return thread;

  }
}
...
}

as you see the interface itself is a contract, which is a combination of:

• 'how' do i call it: e.g. what name does it have, what types are involved. syntax.
• 'what' does it do: what is the effect of using the interface. this is documented either by good naming and/or javadoc.

Above classes are the implementations of the interface which have to follow its contract. Therefore interfaces shouldn't be too strict about 'how' the implementations have to implement the contract (in my case: why is the user not allowed to post/comment -> spammer vs. not-registered).

as said, very simplified example and by far NOT a complete reference for interfaces.

for very funny and practical examples about interfaces (and general object orientation) have a look at head first design patterns. it is nice for novices and also for professionals