4 ms·
Instead of "lack of encapsulation", it's more "lack of private state". In an object oriented language, you have private instance variables and methods to manipu
by jake_morrison 6y ago
Instead of "lack of encapsulation", it's more "lack of private state". In an object oriented language, you have private instance variables and methods to manipulate them. In a functional language, you have functions which manipulate data structures.
If possible, the data structure would have straightforward fields which are public and documented. If necessary, you might make it opaque, expecting only the library which manages the data structure to manipulate it.
One way to think about this is that in functional programming, the "verbs" (functions and manipulation patterns like map) are more generic and the "nouns" (data structures) are less important than in OO languages. See http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-nouns.html http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom...
- chii 6y ago> straightforward fields which are public and documented The rational (whether right or wrong) in OO for private fields and public "manipulator" methods is that the field's representation can be wider than the intended public use. For example, you may store the credit-card number as a string of digits, but only allow the correctly CRC'ed number to be set. Of course, in a more functional paradigm, you would have a credit card number type (which is just a function that strictly enforces the domain and range of the possible valid values), rather than an object which can have independent identity storing the same information.
- leghifla 6y agoThere is no encapsulation like in OOP (data level), but there is another kind of encapsulation (process level): a process is the only one accessing/modifying its own state. And this is very liberating when you need to think about what is going on, what could go wrong...