tags:

views:

195

answers:

9

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!

A: 

Stackoverflow is not a beginners manual or resource. If you have begun implementing something and are stuck on some detail, it's a great resource for finding specific answers.

That said, I'm sure some will be along with some general references shortly.

wallyk
Shouldn't such comments be posted as comments to the OP?
Kornel Kisielewicz
Where is it stated that StackOverFlow is not meant for beginners ? You are always a learner as long as you have to ask questions - That's what SO is all about.
this. __curious_geek
it is this kind of response that discourages good budding programmers
Here Be Wolves
The only question someone shouldn't post is their homework without attempting it ^^
envalid
@this.__curious_geek: it's not explicitly written, but screams from between the lines. Go ahead: ask a newbie question about some facet of programming and observe the tone of responses.
wallyk
the beginner always ask questions with the image that they already known everything,don't they?
kidsoul
Next coming up "This world is not a beginners' training ground. Newborns should not bother their parents with such trivial matters like potty training, proper use of spoon, good manners"
Stefano Borini
+3  A: 

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

Kornel Kisielewicz
anyway,thank you for the wiki search
kidsoul
+1  A: 

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.

BalusC
that is an excellent example,i just hoped they were written by you.yes,you see the point,or fimilar with the details...
kidsoul
I don't get you.
BalusC
+3  A: 

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

Understanding interfaces

Chip Uni
i really appreciate your answer,but better understanding the interfaces needs some more job-close programming examples
kidsoul
kidsoul -- Do you have a more specific question that we can answer? The question that you give is very general; I don't know how it's possible to answer it.
Chip Uni
+2  A: 

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.

No Refunds No Returns
A: 

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

Here Be Wolves
+1  A: 

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.

Stefano Borini
A: 

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

manuel aldana