CODEWITHSUNDEEP
java-8functional-programmingdomain-driven-designimmutabilityvavr
Gopal S Akshintala
Gopal S Akshintala

Reputation: 1973

Java: Are Instance methods Prohibited for Domain Objects in Functional Programming?

Since Functional Programming treats Data and Behavior separately, and behavior is not supposed to mutate the the state of an Instance, does FP recommend not having instance methods at all for Domain Objects? Or should I always declare all the fields final? I am asking more in the context of Object oriented languages like Java.

Upvotes: 3

Views: 392

Answers (3)

Niko
Niko

Reputation: 401

Your fields should be final, but functional code and instance methods are not mutually exclusive.

Take a look at the BigDecimal class for example:

BigDecimal x = new BigDecimal(1);
BigDecimal y = new BigDecimal(2);
BigDecimal z = a.add(b);

x and y are immutable and the add method leaves them unchanged and creates a new BigDecimal.

Upvotes: 0

Robert Bräutigam
Robert Bräutigam

Reputation: 7744

Since Functional Programming treats Data and Behavior separately,

I heard that said a lot, but it is not necessarily true. Yes, syntactically they are different, but encapsulation is a thing in FP too. You don't really want your data structures exposed for the same reason you don't want it in OOP, you want to evolve it later. You want to add features, or optimize it. Once you gave direct access to the data you've essentially lost control of that data.

For example in haskell, there are modules, which are actually the data + behavior in a single unit. Normally the "constructors" of data (i.e. the direct access to "fields") are not available for outside functions. (There are exceptions as always.)

does FP recommends not having instance methods at all for Domain Objects

FP is a paradigm which says that software should be build using a (mathematical) composition of (mathematical) functions. That is essentially it. Now if you squint enough, you could call a method a function, with just one additional parameter this. Provided everything is immutable.

So I would say no, "FP" does not explicitly define syntax and it can be compatible with objects under certain conditions.

I am asking more in the context of Object oriented languages like Java.

This is where it kind-of gets hazy. Java is not well suited to do functional programming. Keep in mind, that it may have borrowed certain syntax from traditional FP languages, but that doesn't make it suitable for FP.

For example immutability, pure functions, function composition are all things that you should have to do FP, Java has none of those. I mean you can write code to "pretend", but you would be swimming against the tide.

Upvotes: 2

VoiceOfUnreason
VoiceOfUnreason

Reputation: 57299

does FP recommends not having instance methods at all for Domain Objects?

In the Domain Driven Design book, Eric Evans discusses modeling your domain with Entities, and Value Objects.

The Value Object pattern calls for immutable private data; once you initialize the value object, it does not change. In the language of Command Query Separation, we would say that the interface of a Value Object supports queries, but not commands.

So an instance method on a value object is very similar to a closure, with the immutable private state of the object playing the role of the captured variables.

Upvotes: 0

Related Questions