Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

If I want to program in a "functional" style, with what would I replace an interface?

interface IFace
   string Name { get; set; }
   int Id { get; }
class Foo : IFace { ... }

Maybe a Tuple<>?

Tuple<Func<string> /*get_Name*/, Action<String> /*set_Name*/, Func<int> /*get_Id*/> Foo;

The only reason I'm using an interface in the first place is because I want always want certain properties/methods available.

Edit: Some more detail about what I'm thinking/attempting.

Say, I've got a method which takes three functions:

static class Blarf
   public static void DoSomething(Func<string> getName, Action<string> setName, Func<int> getId);

With an instance of Bar I can use this method:

class Bar
   public string GetName();
   public void SetName(string value);

   public int GetId();
var bar = new Bar();
Blarf.DoSomething(bar.GetName, bar.SetName, bar.GetId);

But that's a bit of a pain as I have to mention bar three times in a single call. Plus, I don't really intend for callers to supply functions from different instances

Blarf.DoSomething(bar1.GetName, bar2.SetName, bar3.GetId); // NO!

In C#, an interface is one way to deal with this; but that seems like a very object-oriented approach. I'm wondering if there's a more functional solution: 1) pass the group of functions together, and 2) ensure the functions are properly related to each other.

share|improve this question
You wouldn't. Interfaces for datatypes are perfectly fine (though you would favor immutable objects). –  Telastyn Mar 3 '13 at 4:21
Chapter 2 of the SICP is pretty much about this. –  user16764 Mar 3 '13 at 4:37
After rereading your question, I'm curious what specific functionality you're trying to accomplish? What you appear to be asking for is how to do oo style side-effectful programmin against an instance in a functional style, which doesn't make sense.. –  Jimmy Hoffa Mar 3 '13 at 4:53
The answer would be language-dependent. In Clojure you can use clojure.org/protocols, where the only soft area is the types of parameters that the functions must operate on - they are an object - that is all you know. –  Job Mar 4 '13 at 5:22
Make it simple: a struct containing those method pointers, plus a function to initialize it from an object instance. Why Haskell? ;) –  mlvljr Aug 6 '13 at 20:44
add comment

5 Answers

up vote 5 down vote accepted

Don't treat functional programming as a thin veneer over imperative programming; there's much more than just a syntactic difference.

In this case, you have a GetID method, which implies uniqueness of objects. This is not a good approach to writing functional programs. Perhaps you could tell us the problem you are trying to solve and we could give you more meaningful advice.

share|improve this answer
"You must think in Russian." –  Dan Mar 4 '13 at 13:53
Fair enough; my real problem isn't particularly interesting. I've already got things working just fine in C# (github.com/JDanielSmith/Projects/tree/master/PictureOfTheDay if you really want to look at the code), but it would be fun to do in in a more functional style while still using C#. –  Dan Mar 4 '13 at 14:00
add comment

Haskell and it's derivatives have typeclasses which are similar to interfaces. Though it sounds like you're asking about how to do encapsulation, which is a question regarding type systems. The hindley Milner type system is common in functional languages, and it has data types that do this for you in varying fashion across languages.

share|improve this answer
+1 for typeclasses - the main difference between a Haskell typeclass and a Java interface is that the typeclass is associated with the type after both are separately declared. You can use an old type through a new "interface" as easily as you can use an old "interface" to access a new type. For data hiding, you hide the implementation of the type in a module. At least according to Bertrand Meyer of Eiffel fame, an OOP class is a kind of module. –  Steve314 Mar 3 '13 at 16:31
add comment

There are a few ways to allow a function to deal with multiple inputs.

First and most common: Parametric Polymorphism.

This lets a function act on arbitrary types:

--Haskell Example
id :: a -> a --Here 'a' is just some arbitrary type
id myRandomThing = myRandomThing

head :: [a] -> a
head (listItem:list) = listItem

Which is nice, but doesn't give you the dynamic dispatch that OO interfaces have. For this Haskell has typeclasses, Scala has implicits, etc

class Addable a where
   (<+>) :: a -> a -> a
instance Addable Int where
   a <+> b = a + b
instance Addable [a] where
   a <+> b = a ++ b

--Now we can get that do something similar to OO (kinda...)
addStuff :: (Addable a) => [a] -> a
-- Notice how we limit 'a' here to be something Addable
addStuff (x:[]) = x
addStuff (x:xs) = x <+> addStuff xs
-- In better Haskell form
addStuff' = foldl1 <+>

Between these two mechanisms, You can express all sorts of complex and interesting behaviors on you're types.

share|improve this answer
You can add sintax highlighting hints when the language in the answer doesn't match the language in the question. See my suggested edit for example. –  hugomg Mar 4 '13 at 16:00
thanks! good to know –  jozefg Mar 4 '13 at 16:35
add comment

The basic rule-of-thumb is that in FP programming functions do the same job as objects do in OO-programming. You can call their methods (well, the "call" method anyway) and they respond acording to some encapsulated, internal rules. In particular, every decent FP language out there lets you have "instance variables" in your function with closures / lexical scoping.

var make_OO_style_counter = function(){
   return {
      counter: 0
      increment: function(){
          this.counter += 1
          return this.counter;

var make_FP_style_counter = function(){
    var counter = 0;
    return fucntion(){
        counter += 1
        return counter;

Now the next question is what do you mean by an interface? One approach is using nominal interfaces (it conforms to the interface if it says it does so) - this one usually depends a lot on what language you are using so lets leave it for latter. The other way to define an interface is the structural way, seeing what parameters thing receive and return. This is the sort of interface you tend to see in dynamic, duck-typed languages and it fits very well with all of FP: an interface is just the types of the input parameters to our functions and the types they return so All functions matching the correct types fit the interface!

Therefore, the most straightforward way of representing an object matching an interface is to simply have a group of functions. You usually get around the uglyness of passing the functions separately by packing them in some sort of record:

var my_blarfable = {
 get_name: function(){ ... },
 set_name: function(){ ... },
 get_id:   function(){ ... }


Using naked functions or records of functions will go a long way in solving most of your common problems in a "fat-free" manner without tons of boilerplate. If you need something more advanced than that, sometimes languages give you extra features. One example people mentioned is Haskell type classes. Type classes essentially associate a type with one of those records of functions and lets you write things so the dictionaries are implicit and get automatically passed to inner functions as appropriate.

-- Explicit dictionary version
-- no setters because haskell doesn't like mutable state.
data BlargDict = BlargDict {
    blarg_name :: String,
    blarg_id   :: Integer

do_something :: BlargDict -> IO()
do_something blarg_dict = do
   print (blarg_name blarg_dict)
   print (blarg_id   blarg_dict)

-- Typeclass version   
class Blargable a where
   blag_name :: a -> String
   blag_id   :: a -> String

do_something :: Blargable a => a -> IO
do_something blarg = do
   print (blarg_name blarg)
   print (blarg_id   blarg)

One important thing to note about typeclasses however is that the dictionaries are associated with the types, and not with the values (like what happens in the dictionary and OO versions). This means you that the type system doesn't let you mix "types" [1]. If you want a list of "blargables" or a binary function taking to blargables then typeclasses will constrain everything to be the same type while the dictionary approach will let you have blargables of different origins (which version is better depends a lot in what you are doing)

[1] There are advanced ways to do "existential types" but its usually not worth the trouble.

share|improve this answer
add comment

I think it's going to be language specific. I come from a lispy background. In many cases interfaces with state break the functional model to a degree. So CLOS, for example, is where LISP is less functional and closer to an imperative language. Generally, required function parameters combined with higher level methods are probably what you're looking for.

;; returns a function of the type #'(lambda (x y z &optional a b c)

(defun get-higher-level-method-impl (some-type-of-qualifier) 
    (cond ((eq 'foo) #'the-foo-version)
          ((eq 'bar) #'the-bar-version)))
share|improve this answer
add comment

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.