7.5.1 Decorator Pattern (pp.201-202)

The link between the Decorator Pattern and discrimnated unions seems a bit tenuous.

[Expert F# p.67]
"Note Discriminated unions are a powerful and important construct and are useful when modeling a finite, sealed set of choices. ... They are by design, nonextensible: subsequent modules cannot add new cases to a discriminated union. This is deliberate: you get strong and useful guarantees by placing a limit on the range of possible values for a type. Extensible types can be defined through the use of records of functions and object interface types, discussed in Chapter 5 and Chapter 6."

The Decorator Pattern typically is applied in situations where the ConcreteComponent (object hierarchy) is closed to modification (that is, sealed) and we desperately need to extend it (later - possibly dynamically).

So there doesn't seem to be much of an overlap in the intent of the two constructs.

Furthermore it is questionable whether TitledPart is in fact a decorator - it is more likely just another type of CompositeComponent (as there is no restriction on the number of different classes that can act as CompositeComponents). In the XML the title text could have just as easily been placed in a child element to the titled element rather than an attribute value (how do you italicize a single word in the title if it is stuck in an attribute?). While the TitledPart could be viewed as "decorating" the contained TextPart, it can also be viewed (especially looking at the document) as vertical SplitPart were the first TextPart has a larger font and shorter text than the next. So the TitledPart isn't actually needed unless you want to identify the title text as such.

If the point is to show that the (object-oriented) problems that many GoF patterns solve intrinsically do not occur in functional language programming, ala Functional Programming For The Rest of Us:

"In a functional language one does not need design patterns because the language is likely so high level, you end up programming in concepts that eliminate design patterns all together."

then that may be best relegated to an appendix.

(Does Functional Programming Replace GoF Design Patterns?
Peter Norvig: Design Patterns in Dynamic Programming)

Message was edited by: tempusfugit

This artical :
http://www.defmacro.org/ramblings/fp.html
looks like same with :
http://en.wikibooks.org/wiki/Computer_programming/Functional_programming

good literary style, like "Real World .. ", and i think it is very important .. _

Hi,
yes, I admit that relation between this way of using discriminated unions and the Decorator Pattern is a bit tenuous. However, that's probably always the case when looking for some relations between FP and OO code. The similarity I see is mainly in the structure they represent. Not in the goals and problems they try to solve. But that's all determined by the fact that in functional design, you're more often working with sealed choices and you have different kinds of problems than when developing OO systems.

I believe the key problem in functional programming is designing the data structure and I hope that the relation with OO pattern can suggest in which cases we can use discriminated union to represent something like decoration (the most famous example of Decorator Pattern with adding scrollbars to a widget would be probably solved like this in functional program).


>> In a functional language one does not need design patterns because the
>> language is likely so high level, you end up programming in concepts that
>> eliminate design patterns all together.

I know people often say that, but I'm not really convinced. It doesn't need object oriented design patterns, but it may need some different patterns. After all, patterns just describe common solutions to tricky problems, so the statement above essentially says that there are no difficult problems in functional programming I wish that would be true...

An interesting discussion about this topic is here:
http://stackoverflow.com/questions/327955/does-functional-programming-replace-gof-design-patterns

"It doesn't need object oriented design patterns, but it may need some different patterns. After all, patterns just describe common solutions to tricky problems, so the statement above essentially says that there are no difficult problems in functional programming I wish that would be true..."

It is true that with "functions as values" the "strategy pattern" becomes a first class construct and that in itself is powerful. And patterns in general are also an invaluable tool to make communication between designers/developers more concise. However many neophytes go pattern mad. In the context of object orientation I always try to emphasize that the principles of object oriented design are far more important than OO patterns. Furthermore once you understand the principles of OOD, many patterns become much easier to understand as the patterns are the result of sound application of the principles under a certain set of design constraints.

So in the context of functional programming I imagine that it is of primary importance for the newcomer to understand the "principles of functional design" which themselves are probably based on concepts like "functions as values", "higher order functions", "partial function application", "currying", "function composition", etc.