Back to Questions
2.4k
views4
comments
Writer's block while writing F# code
f#classespackaging

I believe I have a resonable grasp of F# now but still 'suffer' from OO thinking.

In OO you typically break down a problem into multiple interacting objects. Most OO environments allow packaging of class code into multiple files (e.g. 1 file per class). This makes working on a single or tightly coupled classes relatively easy because one has to sort through less code at a time.

In F# declaring multiple type that depend on each other one has to use the form:

type Type1 = ...

and Type2 = ...

and Type3 = ...

This sort of forces all code to go into a single file and this is a stumbling block for me currently.

One idea is to first create a set of 'interface' types with abstract public properties and put those in a single file. Then put 'implementation' classes in separate files.

It seems that I can use the same 'namespace' name in multiple files (but can't do that with 'module' names).

Is this a reasonable approach? Can anyone suggest alternative approaches or practices that will address this issue.

.

Yes, given that mutually recursive classes must all go in one file, if you want to break such code up into multiple files, you must either

  • redesign to break the dependencies (so there is less coupling/cohesion among the classes)
  • refactor to introduce interfaces as a point of indirection, so the light interfaces are coupled but the heavy implementations are decoupled

Both strategies may have other side-benefits you might appreciate.

(A future version of F# is likely to introduce a new language construct that allows recursive groups to span multiple files or namespaces.)

By on 6/7/2010 9:31 AM ()

Why not just ditch the OO way of designing your code and go completely functional. which would mean using records to build your datastructures and declaring the operations that operate over those datastructures as functions.

By on 6/7/2010 3:33 PM ()

Why not just ditch the OO way of designing your code and go completely functional. which would mean using records to build your datastructures and declaring the operations that operate over those datastructures as functions.

Because OO and encapsulated private data are good things, and because member functions are more discoverable than free functions.

Abandoning OO is a bad idea. Use FP in the small, but the original poster is clearly thinking 'in the large'.

See also:

How does functional programming affect the structure of your code?

By on 6/7/2010 4:09 PM ()

Maybe you can try and abstract away the bits that make those types dependent on each other. Put them into a separate class, then you have independent types that can go into separate files.

It may not be this easy in your case though.

By on 6/7/2010 7:55 AM ()

    Topic tags

    IntelliFactory Offices Copyright (c) 2011-2012 IntelliFactory. All rights reserved.
    Home | Products | Consulting | Trainings | Blogs | Jobs | Contact Us | Terms of Use | Privacy Policy | Cookie Policy     		Built with WebSharper