From OO to functional programming at 10,000 feet

Question

I have been using f# and Haskell to learn functional programming for a while now. Until I can get f# approved at our company I must still use c#. I am still trying however to stay in the functional style as I have noticed several benefits.

Here is a typical problem.

1. There is a key-set table in the database with 3 keys (6.5 million rows)
2. There are 4 other supporting tables of small to medium size.
3. There are complex formulas based on several inputs.

I have to use data from all of the above to calculate a value and associate it with each key-set row and send it back to the database. There is a lot of lookups to the other 4 tables. For performance sake it is all done in memory.

I know exactly how I would do the in OO with static dictionaries, object models, strategy patterns and so forth but in a functional way I cannot get rid of the bad smell of using some of these constructs.

I am currently making the following assumptions for a functional solution.

1. Static dictionaries are bad. It seems the function could have side affects.

2. I need an Calculate function the takes an immutable object(s) and returns an immutable object with the three keys and the calculated value. Inside this function there could be another function in the same style.

3. Traditional OO patterns are probably not going to work.

How would you design this at a high level?

Am I wrong? Have I missed anything?

Answer 1

No, you are not not wrong. Both OOP and functional programming have their benefits and their drawbacks.

A developer needs tho know how and when to use each development style. It's fortunate that C# supports in a way both development styles.

In my opinion, and I use both functional and oop programming styles on a daily bases, oop is best when dealing with complex interactions and inter dependencies between various abstract artifacts (entities, nouns etc. ). Functional programming is best used when dealing with algorithms, data transformations etc. e.g. situations where the complexity of statements needed to solve a given problem is great.

I generally use object oriented programming on my domain (entities, aggregates, value objects, repositories and events) and reserve functional programming for my service objects.

Most of the the time it comes to a smell, or feeling which is best, since in software development aren't clear cut cases either way, and experience and practice often is the best judge for a given choice.

Answer 2

Functional programming in an OO language tends to be wrong. It produces overly verbose code that doesn't perform well and is more error prone (such as writing deeply recursive functions in a language that doesn't support tail calls.)

Blockquote 1. Static dictionaries are bad. It seems the function could have side affects.

Either it does or does not have side effects. A static dictionary can be a good way to implement memoization in an OO language.

Blockquote 3. Traditional OO patterns are probably not going to work.

OO patterns work well in an OO language trying to shoe horn FP techniques into a OO language will produce verbose and brittle code. It is rather a lot like trying to use a screw driver with hammer techniques sure it produces a result but there are better ways. Try to use your tools in the best way possible. Certain FP techniques can be useful but completely ignoring the language isn't going to make for good quality code.

Answer 3

If your looking for speed you may want to consider the underlying data structures your using. Dictionary<> in C# is a hash table while SortedDictionary<> in C# is a binary search tree.

F# and Haskell both do a good job of representing tree data structures. You may want to consider using a more specific data structure over the default ones C# provides.

At a high level I would figure out what performance characteristics your formulas display and compare them to different data structures (wikipedia is a good source if you need a refresher). Once you figure out what data structures to use then I'd worry about what implementations to use.