IDEA: Dining Philosophers with a "Strategy" pattern

[David James]

I was thinking about taking a stab at the same Dining Philosophers
problem that we talked about yesterday, but perhaps breaking it into
these pieces:
1. A common piece for the simulation that handled the nuts and bolts
of it:
a. defines the number of philosophers at the table
b. defines the number of forks available
c. defines that there are three states for a philosopher: thinking,
eating, and asking for forks (so he can eat)
d. displaying the simulation at a snapshot in time
2. A pluggable "strategy" piece that describes:
a. how the initial allocation of forks takes place
b. how the dynamic allocation of forks takes place

Perhaps between now and the next meeting we could write the underlying
part of the simulation. Then at the next meeting we could try out
some different strategies that each of us write?

In OO speak, the pattern that I'm hinting at is commonly called the
Strategy pattern. There are other related patterns surely, I don't
want to put too fine a point on it, since object oriented programming
and functional programming probably don't mesh exactly.

This would be interesting to me because I'm most familiar with object
oriented programming, and that is sort of the "default way" that I
think about structuring programs. I'm learning more about functional
programming, I think it will be interesting for me at least (and maybe
others) to see how to structure functional programs so that they are
easily understood one piece at a time.

[Keith Bennett]

David -

Interesting idea. It would seem to me that a functional language like
Clojure would make implementing the Strategy pattern simpler than in
other languages like Java since it is so easy to pass functions
around.

In a way, I guess one could also argue that functional languages have
been heavily using the Strategy pattern since before it was named,
since so often a function is being passed to operate on a sequence/
list. And, while the Strategy pattern refers to accomplishing a given
task in different ways (and not different tasks in different ways),
I'm sure that this was done pretty often over the years in functional
languages.

I like the idea of explicitly designing the app using the Strategy
pattern because I think it will result in more cohesive (and therefore
cleaner) code. I'd like to look at the code again, though -- it might
already be doing that, and I just didn't notice.

I posted my previous message about a fork allocation strategy before
absorbing your message, but I guess that's exactly what I was offering
-- an alternate strategy for the initial fork allocation, like you
say. Optimal strategy depends on the objective, though -- I was
seeking to optimize clarity, and, as I understand it, Michael was
illustrating an interesting mathematical implementation for
educational purposes.

I guess in order to support multiple strategies, we'd have to define
the parameters and return value for all implementations of a given
strategy. That might be a good first step. This might require
revisiting the data design. All in all, I think it would be a great
exercise. We might wind up with exactly the same program Michael
showed us, but we'd understand it a lot better. ;)

- Keith

[Keith Bennett]

One more thing...

It would be really cool to add an entry to the Wikipedia article on
Strategy Patterns for Clojure:

http://en.wikipedia.org/wiki/Strategy_pattern)

There are examples in:

# 1 Code Examples

* 1.1 C++
* 1.2 Java
* 1.3 Python
* 1.4 C# 3.0
* 1.5 C#
* 1.6 ActionScript 3
* 1.7 PHP
* 1.8 Perl

... but no functional languages.

- Keith