Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Recently I've started to put almost all of my data structures into interfaces, and many of the classes that contain pieces of logic code as well, depending on how much work they are. I find that this makes development of applications much easier because I can easily swap out parts of my code when they do not work as well as intended without changing the rest of the application and swap them back in when I have corrected them, or if I need something simpler for the time being. I was wondering if I'm developing a bad habit here.

Is this a anti-pattern I'm using here, or is it okay to do this?

share|improve this question
up vote 5 down vote accepted

Well, "Program to an interface, not an implementation" is a long-standing design pattern (Gang of Four 1995:18). It's generally a good practice, especially where you want to decouple two modules so you can reason about each one independently.

It's mostly used in the form of dependency injection (that is, you inject dependencies that conform to some interface). I have also used interfaces for my data structures and I find it works well. If you have a method that takes data and stores it into a database, you might have two different sources of data that get stored... and I've had cases where I have two different concrete classes that implement that interface, one from a data logging source and another from a manual entry.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.