Refx :: Is OOP Better for Structuring your Code?
Join the DZone community and get the full member experience.Join For Free
Programming languages that offer more power and flexibility have been lately gaining momentum. Johnatan Tang highlights, however, the flexibility vs. productivity tradeoff in terms of program structure. Whereas multi-dispatch languages provide more flexibility in arranging code, traditional object orientation makes organizing programs easier.
Originally posted on http://www.infoq.com/news/2008/11/oop-vs-fp-4-code-structure
Programming languages that offer more power and flexibility have been lately gaining momentum. Johnatan Tang highlights, however, the flexibility vs. productivity tradeoff due, amongst other things, to the fact that traditional object orientation makes organizing programs easier and more straightforward.
He argues that in languages with single dispatch, “given a parameter or other value, you know exactly what you can do with it”. Whereas in statically typed languages code is more revealing about values involved, in structurally typed languages it is more general, but still gives an immediate idea what operations are available on a given value. And for both, statically and structurally typed languages, it is pretty clear what to do if you want to perform an operation that is not supported by a given object:
You write a method that performs that operation. This is problematic if you don’t control that class, which is why Ruby and C# have moved to open classes. […]
And it’s usually obvious where this method should go: on the class that you need to manipulate.
In multi-dispatch languages, it is much less obvious where a method should be written and “which parameter of the new method might take [a given] value”. This provides more flexibility in arranging code but this implies that more decisions should be taken about it and more efforts should be provided to keep these decisions in mind:
And then every time someone uses the method, they need to remember where it was defined and add the appropriate import statement. If they forget, they might get behavior they don’t expect, as the appropriate method for the given generic function won’t even have been loaded.
Establishing conventions can be considered a solution to this issue. However, Tang believes that “conventions that aren’t enforced by the language tend not to be followed”. Moreover, having tried to define some patterns for modules arrangements, he also asserts that “this is inherently problem-domain-specific: there’s no one right organizing principle that applies to everyone’s programs.”
Hence, according to Johnatan Tang there is no obvious solution to this tradeoff of flexibility vs. productivity in organizing programs. What about your favorite languages? What solutions could you find? And, given your experience, is there any convenient compromise between the two?
From Sadek Drobi's blog
Opinions expressed by DZone contributors are their own.