## Principles or patterns in FP

I've been reading articles on this site on and off for some time now. I thought I might ask my question here (I wasnâ€™t sure where else to post, please bear with me). I have been programming in Java for a long time and recently I started programming in Erlang. I started developing a product (service) in Erlang.

When I write code in Java, I try to adhere to principles of OOP to a great extent and I find that they actually help me. Like for instance, the Open/Closed principle makes code maintenance easy (among other things). With Open/Closed principle I write classes in such a way that there won't be a need to edit them after a few months. I think we can agree that it is risky editing a file when you re-visit after a few months. So for example, if my customer wants to calculate area of a new Shape, say, a Triangle, I can easily create a new type without modifying the existing code:

abstract class Shape {
public abstract float area();
}

class Circle extends Shape {
public Circle(float r) {
}
public float area() {
}
}

class Square extends Shape {
// override area
}


The same in Erlang would be like so, say in shapes.erl:

-module(shapes).
-export([area/1]).
area({square, Side}) -> Side * Side.


To calculate the area of a Triangle, I would have to edit shapes.erl - which is risky because there is a chance I might mess up other functions. To be sure everything runs as expected, I'd have to execute unit tests on *all* functions in this module, increasing my testing time.

Like I mentioned, I am creating a product which will be used as a service. Anything that will help me roll out features or fixes sooner will greatly improve my productivity and keep in mind the costs too. My question - are there any such principles or patterns in FP that I can follow? I searched online but I wasn't satisfied with the results. With time, I will eventually learn some principles but I wanted to get some tips from the experts here. I apologize if this was discussed before, I will be happy with a link to a good article.

Thank you.

## Comment viewing options

### Erlang is all about concurrency

So anything you do with Erlang should probably be all about concurrent processes and messaging. In answer to your immediate question, you could make the objects be processes that receive messages (for example, see my OO Shapes in Erlang). Of course, the larger question is whether you need to reformulate your solutions away from OOP and towards COP (concurrent oriented programming). You could then isolate the tests to operate on processes - keeping them as lean as you would like - with the added benefit that messaging makes for loose-coupling.

### Expression problem

What you've found is one half of the expression problem. As you point out, in the Java example adding a triangle type is easy. You don't have to modify any existing code, you just add a new Triangle class and go. In your functional Erlang example, on the other hand, you would have to modify the existing area function to have one more case.

But there's a duality. If instead of asking you to add a triangle your client asked you to add a perimeter operation then the problem would be flipped. In Erlang you could go as far as to create an entirely new module with the appropriate perimeter implementations for square and circle. The existing module with area in it could be totally left alone. In Java, on the other hand you would have to modify all three existing classes.

This duality between object oriented single dispatch and functional pattern matching is called the expression problem. Here's more on the the issue and how languages attempt to deal with it.

Which brings me to the last point. LtU is about language theory, design, and implementation. While we do sometimes slip a bit into software design as a part of exploring language consequences, your kind of basic how-to question would be better placed on a site like Stack Overflow or the Erlang mailing list.