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.