1

Is it necessary to use interfaces for small projects? I work at a shop writing small custom applications for clients, primarily data manipulation. I'm mostly self-taught but also took some programming classes in college. I've been trying to apply more OO concepts to my coding practices, but I really don't see the need for interfaces in the work that I do. My largest project so far had around 10 classes in it.

Are interfaces necessary for small projects/applications or only for large-scale software systems?

EDIT: This is not a duplicate. I'm asking about using interfaces in general for small projects, not using an interface for when there is only a single implementation...

Improve this question
4

3 Answers 3

Reset to default
1

Short answer: No.

Long answer: There's a trade-off between using a class and an interface. Interface implementations can be swapped at runtime. That's nice because it's flexible - but it also means someone can code up a bad IFoo and pass it to one of your functions that otherwise works fine. With a concrete (and sealed/final) Foo there's only one implementation, so if you get it right, it always works.

Another drawback of interfaces is that they can't inspect the implementation details of other members of that interface. Foo methods can inspect the private variables of other Foos, but IFoos can only look at the interface of other IFoos. This can limit certain optimizations, so if there's only one implementation of an interface it can hurt you without providing any benefits.

Unfortunately mainstream OOP languages don't provide a way to swap class implementations. Ideally you'd be able to have multiple Foo implementations and pick one of them at compile time. However, with an IDE it's not hard to extract an interface out of a class after the fact.

If you don't need to juggle multiple kinds of Foos in the same program there's no need to add an extra layer of indirection with an interface. Even if you do need multiple kinds of Foos in the same program, you don't necessarily need an interface. You can have an abstract base class with a private constructor and implement a finite number of types of Foos as static final inner subclasses. See also How do you encode Algebraic Data Types in a C or Java-like Language.

Interfaces really shine when you don't want to limit the number of possible implementations usable at runtime at all.

EDIT: For a more thorough explanation of the trade-offs involved, see On Understanding Data Abstraction, Revisited.

Improve this answer
4
  • 1
    Unfortunately mainstream OOP languages don't provide a way to swap class implementations - well, not by themselves (not on language level), but that's what DI containers are for. Foo methods can inspect the private variables of other Foos - I think they shouldn't do that. It breaks encapsulation. It smells of bad design. I don't downvote your answer as I don't think it's wrong, but a lot of the views you expressed are debatable to me.
    – Konrad Morawski
    Commented Apr 4, 2014 at 15:12
  • 2
    With a concrete Foo there's only one implementation, so if you get it right, it always works - if it's final / sealed. Otherwise someone can inherit from your Foo and pass you a broken child class.
    – Konrad Morawski
    Commented Apr 4, 2014 at 15:13
  • @KonradMorawski Suppose you're implementing sets. As an interface, computing the union of two sets would be expensive because you have to do all the membership tests as separate operations. With a class, both sets have the same representation and you can exploit that; e.g. with sorted lists computing the union can be done in linear time. I've added a paper to the post that explains more about the trade-off between abstract data types and objects/interfaces.
    – Doval
    Commented Apr 4, 2014 at 16:31
  • @KonradMorawski As another example, consider integers. In order to do plain old bitwise addition you need the bit representations of both integers, but you need not specify or expose which representation you're using (some languages choose to do so, but it's not necessary). Integers are generally abstract data types for efficiency reasons. They could be implemented as interfaces using the Peano Axioms, but then you'd express the number 3 as "the successor of the successor of the successor of zero" and addition would be O(n) instead of O(1).
    – Doval
    Commented Apr 4, 2014 at 16:53
4

Even if you only have a small project, if you want to have unit tests, you'll probably want to use interfaces for your services and dependencies. That way you can inject mock implementations of those in your unit tests.

If you're not doing unit testing, then there are other common uses for interfaces, such as the strategy pattern.

Improve this answer
1
  • This. If you care that your program actually does what it's supposed, then you'll want it to be easily testable. If you want it to be easily testable, you'll want to use interfaces and dependency injection everywhere you can.
    – mo.
    Commented Apr 4, 2014 at 18:36
0

define "necessary"

if two classes must implement the same interface in order to be interchangeably used by some object, then using an interface is technically necessary - though inheriting from a common base class can get around this (for languages that don't support interfaces, for example)

the size of the project is irrelevant

Improve this answer
2
  • I was going to downvote because of the nefarious "define necessary" as if the word necessary was not already defined in the middle ages. But then I was going to upvote because of "size of project is irrelevant". So the two tendencies cancelled out mutually and I didn't vote.
    – Tulains Córdova
    Commented Nov 26, 2014 at 21:36
  • @user61852: a balanced viewpoint ;)
    – Steven A. Lowe
    Commented Nov 26, 2014 at 22:35

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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