Object model in functional style?

Is it at all practical to implement an object model in functional style?

One problem that OOP seems to excel at is describing object models.

For instance, an HTML DOM is a compl开发者_运维百科icated, stateful beast which interfaces directly with the UI and requires programmability from dynamic languages. OOP features tend to come in useful in a lot of ways:

• Member access constraints make interfacing with untrusted code (e.g. javascript) safe
• Accessor functions and properties make binding to the UI much more convenient
• Not having to pass around the object model all the time makes methods a lot simpler.

The UI side of the story might be a bit moot if you're projecting the model via MVVM, but you're still constantly wrestling with state internally.

I'm working in F# for this project so I could easily resort to OOP, but I'm curious as to how far I can push it before it becomes impractical. Are there maybe design patterns or anything?

This is a bit philosophical to have a "correct" answer but okay I'll bite.

In my opinion the problem comes because you consider FP and OO to be juxtapose, they are not. FP and imperative programming are juxtaposed, i.e. using expressions versus using statements.

Part of the problem is that OO lacks a clear definition, well in my opinion anyway. To support this I'd point to Alan Kay who said “Actually I made up the term "object-oriented", and I can tell you I did not have C++ in mind.”, yet most language we consider OO i.e. java/C# take more after C++ than smalltalk.

What OO C++/java/C# style does give us is a nice way to organize our code into models, create data contains add properties to them etc. Non of this is practically un-functional and can be used nice with functional programming.

As you point out a lot of C++/java/C# tend to be stateful, but they don’t have to be, both java and C# have fundamental types such as their string classes that are immutable. It’s true java and C# don’t make it easy to create immutable class but with a bit of effort you can do it.

Which brings us to where is immutable appropriates? In my designs usually start of by making everything immutable, since this makes getting things correct easier, and if I see this causing performance problems I start adding some mutability on the critical paths. The one place immutability is never going to work is GUI controls, which generally contain far too much state to be immutable. Having said that you can get quite a long way building GUI using a immutable “combinator” approach then is then interpreted by mutable gui controls. This is more or less what the WebSharper guy’s do: http://www.intellifactory.com/products/wsp/Home.aspx

Another great resource for the FP/OO debate is Brain’s “How does functional programming affect the structure of your code?” (which greatly influenced my thinking about FP/OO): http://lorgonblog.wordpress.com/2008/09/22/how-does-functional-programming-affect-the-structure-of-your-code/